Mind Port

Demo

About

The problem it solves The problem it solves Today, “agents” are usually not portable, not ownable, and not trustworthy: If you build an agent in one platform, it’s stuck there (or recreated from scratch). Sharing an agent usually means sharing a messy prompt/tools bundle with no clear “source of truth.” Buying/selling an agent is basically impossible to do safely — there’s no clean ownership transfer, no standard way to package it, and no reliable way to know what you’re getting. Teams can’t easily reuse the best internal agents or track which version actually worked. MindPort turns an agent into a real asset: something you can create, run, and transfer ownership of — with a clean interface and repeatable behavior. What people can use it for 1) Reusable “micro-workers” for common workflows Create agents that do one thing extremely well and reuse them endlessly: Pitch / slide outline agent for demos and hackathons PRD / spec writer for product ideas Code review / refactor assistant Study tutor / quiz generator Meeting notes → action items Email / outreach drafts (consistent tone + structure) Instead of rewriting prompts every time, you just pick an agent and run it. 2) Sharing agents without the chaos You can share an agent as a single, structured “brain”: system prompt policy toggles (e.g., “refuse to guess”, “ask clarifying questions”) allowed tools model choice (even if currently a facade) This makes collaboration easier because the agent’s behavior is defined and repeatable, not “whatever prompt someone pasted today.” 3) Safer agent usage through controlled behavior Even before the full encryption/ownership gating is added, the platform design supports safety by construction: Policy toggles let you enforce “don’t guess” and “ask clarifying questions” Tool allow-lists restrict what the agent can do Trace visibility shows what happened (tool calls / steps), which helps debug and builds trust This is useful for workflows where you don’t want silent hallucinations or unpredictable outputs. 4) A marketplace for useful agents Most “agent marketplaces” are just links to prompts. MindPort is about trading something closer to a product: the agent’s “brain” packaged as a structured spec discoverable by metadata (name/description/tags) transferable ownership via the marketplace contract (local testnet first) This creates a path for: creators to ship reusable agents teams to buy proven “agents-in-a-box” instead of reinventing prompts How it makes existing tasks easier ✅ Less time setting up, more time using You stop doing: “where’s that prompt?” “what model/settings did we use?” “which version worked?” And start doing: pick agent → run → iterate ✅ More consistency The same agent spec produces the same style/structure every time (especially with policy + formatting constraints). ✅ Better debugging and trust You get traces and receipts, so it’s easier to explain: why the agent responded a certain way what tools were used what constraints were applied Who it’s for (early adopters) Hackathon builders who want repeatable “project assistants” Students who want study agents they can reuse and refine Devs/teams building internal workflows (“agent templates”) People who want to package and share their best prompts/tools as reusable assets Use of AI tools and agents Here's a write-up for the submission: --- ## Dynamic Agent Construction with Google ADK MindPort doesn't ship pre-built AI agents. Instead, users **design agents at runtime** by defining an `AgentSpec` — a structured blueprint containing a system prompt, behavioral policies (whether to ask clarifying questions, refuse to guess, output format), model selection, and domain tags. The platform then constructs a fully functional AI agent from this spec on every invocation. The Python backend uses **Google's Agent Development Kit (ADK)** to dynamically instantiate agents: ``` User defines AgentSpec → Frontend sends {spec, message} → Next.js API proxy → Python ADK service → Agent built from spec → Response returned with trace + receipt ``` Each run is stateless by design — the `AgentSpec` is the complete source of truth. This means the same spec always produces the same agent behavior, making agents **portable, tradeable, and reproducible**. ## AI Agents as Tradeable NFTs The core innovation is treating the `AgentSpec` as intellectual property that can be tokenized. When a user mints an agent: 1. The agent's metadata (name, description, tags, prompt) is written **on-chain** to the `AgentBrain` ERC-721 contract on 0G network 2. The local agent record is linked to the `tokenId` in Upstash Redis 3. The agent becomes a **tradeable asset** on the escrow marketplace — other users can browse, bid on, and purchase agents using 0G tokens ## Token-Gated Execution Minted agents are **ownership-gated**: only the current NFT holder can run them. This is enforced through a two-step verification on every request: 1. **Client-side**: The user signs a message (`"MindPort Run Authorization\nTokenId: <id>\nNonce: <timestamp>"`) with their wallet, proving they control the address 2. **Server-side**: The Next.js backend verifies the ECDSA signature, then queries `AgentBrain.ownerOf(tokenId)` on-chain to confirm the signer actually owns the token If ownership transfers via the marketplace, execution rights transfer with it — the new owner can run the agent, the previous owner cannot. ## How the Pieces Connect | Layer | Tool/Tech | Role | |---|---|---| | Agent Design | Next.js + shadcn UI | Visual builder for `AgentSpec` creation | | Agent Storage | Upstash Redis | Persistent CRUD for agent blueprints | | Agent Execution | Python + Google ADK | Dynamically builds and runs agents from specs | | Agent Tokenization | Solidity + 0G Network | ERC-721 NFTs representing agent ownership | | Agent Trading | `AgentMarketplace.sol` | On-chain escrow marketplace with ETH bids | | Access Control | wagmi + viem + ECDSA | Wallet-based ownership verification for gated execution | The result is a system where AI agents are **first-class digital assets** — created by anyone, executable on demand, verifiably owned on-chain, and transferable through a decentralized marketplace.

How it's made

Challenges we ran into Here's a write-up based on the actual bugs and hurdles from building this project: --- ## Hardhat v3 Silently Ignoring `--network` The most frustrating bug was during 0G testnet deployment. Running `npx hardhat run scripts/deploy.ts --network zerog` deployed to the **local Hardhat network** instead of 0G. The deploy script read `process.env.HARDHAT_NETWORK` to determine the target — a pattern that works in Hardhat v2. Turns out **Hardhat v3 does not populate that env var from the `--network` CLI flag**. This isn't documented anywhere obvious. The fix was parsing `process.argv` directly to extract the network name — dead simple once diagnosed, but cost over an hour of "why is this deploying to the wrong chain?" ## Wagmi v2's `useChainId()` vs Reality The wallet "wrong chain" warning was broken for days without us noticing. `useChainId()` returns the **configured** chain ID from the wagmi config (always 31337), not the chain MetaMask is actually connected to. The wallet could be on Ethereum mainnet and the UI would show everything as fine. The fix: use `useAccount().chain?.id` instead, which reflects the wallet's actual connected chain. ## ERC-721 TokenId Extraction After Mint After a successful mint transaction, extracting the `tokenId` from the receipt silently failed. The initial approach parsed the `Minted` event from logs, but the topic hashes and address comparisons were case-sensitive while some RPC responses returned mixed-case addresses. We implemented a two-layer strategy: first search for the standard ERC-721 `Transfer(address,address,uint256)` event with case-insensitive matching, then fall back to calling `totalMinted()` on the contract. ## Vercel Blob: Private Store ≠ Public Access Deploying to Vercel immediately broke agent storage with: `Cannot use public access on a private store`. New Vercel Blob stores default to **private** access, which means `access: "public"` in `put()` calls is rejected, and `blob.url` returns URLs that require authentication. The fix was switching to `access: "private"` and using `blob.downloadUrl` (a short-lived signed URL) instead of `blob.url` for reads. We later moved to **Upstash Redis** entirely — blob storage is designed for large files written once, not small JSON documents with frequent CRUD. ## Ephemeral Hardhat State Every time the Hardhat node restarted, all balances, contracts, and transaction history vanished. MetaMask would show a connected account with 0 ETH and cached nonces that didn't match the fresh chain state. This caused cryptic `Sender doesn't have enough funds` errors. The solution was a dedicated `fund.ts` script and a clear dev workflow checklist: fund wallet → deploy contracts → export addresses → restart Next.js. Sounds obvious in retrospect, but when you're debugging a "transaction failed" error, the last thing you suspect is that your entire blockchain evaporated. ---