What's next for blockchain-agent-treasury
Inspiration
AI agents can move quickly, but payments should not require giving an agent a private key or asking it to guess through wallet UI. We built x402 Agent Treasury around a safer division of labor: the agent handles discovery and exact preparation, while the person keeps custody and makes the final signing decision.
What it does
The deployed app exposes seven narrow WebMCP tools directly from the page. An agent can:
- list five configured EVM, Solana, and Gno payment rails
- distinguish testnet-ready paths from independently locked mainnets
- prepare wallet-bound, short-lived x402 terms
- inspect the live Gno Pearl gateway and scheduled indexer
- search canonical Pearl activity
- open the matching human review screen
- retrieve one exact durable payment receipt
The consequential boundary stays visible. Preparation never signs or settles. The wallet review shows network, asset, amount, recipient, payer, resource, and expiry before a person approves.
How we built it
The application uses Next.js, React, and TypeScript on Vercel, with Neon PostgreSQL as the authoritative challenge, payment, and audit store. The top-level page registers imperative tools through document.modelContext.registerTool(). Each tool has a strict JSON Schema, bounded output, cancellation support, and read-only or state-changing annotations.
The chain-neutral payment layer supports Base Sepolia USDC through EIP-1193 and EIP-712/EIP-3009, Solana Devnet USDC through Wallet Standard and a sponsored v0 transaction, and Gno Pearl WUGNOT through Adena and TM2 RPC. Ethereum, Solana, and Gno mainnet paths remain independently fail-closed.
Server-issued challenge IDs, payment IDs, expected payer, recipient, amount, asset, resource hash, expiry, and unsigned payload fingerprints are bound together. The server rechecks the terms immediately before signing and prevents replay or cross-challenge substitution.
Chrome support is delivered as a progressive enhancement with explicit origin isolation and a same-origin WebMCP permissions policy. The same deployed page also works in ChatGPT's in-app browser.
Challenges we ran into
The hardest part was preserving human authority without reducing WebMCP to a read-only demo. The agent needed enough power to prepare useful work, but not enough power to silently change recipients, tokens, networks, or settlement endpoints.
Multichain signing also differs significantly. EVM uses typed authorization, Solana uses a short-lived blockhash and signed v0 message, and Gno uses Adena-encoded transactions. We kept one agent-facing workflow while retaining chain-specific verification.
Chrome's experimental implementation additionally requires the testing flag and an origin-isolated document. We added explicit Origin-Agent-Cluster and tools permissions headers and verified that all seven registrations complete in a fresh Chrome tab.
Accomplishments that we're proud of
- a working public WebMCP deployment with seven registered tools
- one coherent human-agent handoff across three chain families
- independently locked mainnet gates
- durable PostgreSQL challenge and receipt records
- tamper, replay, policy, settlement, and WebMCP safety coverage
- 119 automated tests passing on the submission build
What we learned
Agent-native interfaces are strongest when tools expose intent and constraints, not when they merely automate clicks. For sensitive actions, a prepared object shared by the agent, server, UI, and wallet is a better collaboration primitive than an invisible autonomous action.
What's next
We plan to add continuously indexed Gno activity, complete recorded real-wallet testnet acceptance on every rail, and expand the same human-approved pattern to paid compute and storage workflows.
Built With
- next.js
Log in or sign up for Devpost to join the conversation.