Public systems as the source of truth
World Chain, ENS, Base, and Hedera hold registry state, profiles, payments, and history. The Next.js server coordinates them but does not own a competing catalog or reputation database.
A2A
A solo World App prototype that connects creator verification, agent discovery, pay-per-call execution, and reputation without maintaining a separate product database.
Problem
AI agent marketplaces need a way to verify creators, identify agents across platforms, handle payments, and track reputation without relying on a single central database.
Contribution
I built and deployed the smart contracts, Next.js application, ENS integration, x402 payment flow, and Hedera-based reputation system.
Result
Working prototype completed during ETHGlobal Cannes.
System
A Next.js application with World ID verification, a World Chain registry contract, ENS records, x402 USDC payments on Base, and Hedera HCS reputation receipts.
Main challenge
Coordinating registration, metadata, settlement, and reputation across World Chain, ENS, Base, and Hedera within the hackathon timeline.
Overview
A2A was a solo ETHGlobal Cannes prototype for publishing and invoking AI agents inside World App. World ID verifies creators, ENS stores each agent's public profile, x402 handles per-request USDC payments on Base, and Hedera HCS records reputation events.
The application does not use a separate product database. Registry state is stored on World Chain, public metadata in ENS records, payment transactions on Base, and reputation history in an append-only Hedera HCS topic.
Identity and discovery
World ID verification produces a nullifier hash used by AgentRegistry to enforce a five-agent limit per verified creator. The contract also stores a hash of the creator's signed AgentKit credential for agent-to-agent verification.
Each agent receives an ENS subname whose text records describe its endpoint, price, capabilities, payment address, verification level, and rating. Price or payout details can be updated through ENS without changing the registry contract.
Payments and reputation
An unpaid invocation returns HTTP 402 payment terms. MiniKit signs an EIP-3009 USDC authorization, the client retries with the payment header, and the facilitator settles on Base before the agent endpoint is invoked. The response includes the settlement transaction hash.
Completions, failures, reviews, and composed calls are written as typed events to Hedera HCS. Mirror Node queries derive counts and ratings, and reviews are deduplicated by World ID nullifier before aggregates are written to ENS.
Agent-to-agent composition
A registered agent can call another agent through the same credential and x402 flow. The target receives the caller's verified agent identity and declared capabilities, while Hedera HCS records the completion for the target and the composition event for the caller.
Technical deep dive
01Requestprompt → API route
02402payment required + terms
03SignEIP-3009 · MiniKit
04Retrypayment header attached
05Settlefacilitator → USDC
06Invokeagent endpoint runs
07ReceiptHedera HCS log
Key decisions & why
x402 over on-chain escrow
EIP-3009 authorizations fit low-value, per-request pricing: one wallet signature, no platform custody, and facilitator-settled USDC with an on-chain receipt.
Hedera HCS for reputation, not Ethereum
Reputation is an append-only event stream rather than contract state. HCS provides ordered low-cost messages, and Mirror Node reads support derived ratings without maintaining an editable application ledger.
Human-verification cap in the contract
AgentRegistry enforces the five-agent limit against the World ID nullifier. Because the rule is implemented in the contract, the API cannot register additional agents for the same verified creator.
Stack