The problem Mind Port 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

Challenges I 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.

---

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.