Key Features
- Identity Registry: Portable agent identifiers based on ERC-721 NFTs
- Reputation Registry: Standardized feedback and rating system for agents
- Validation Registry: Independent verification hooks where third-party validators can attest to agent outputs—supporting stake-secured re-execution, zkML proofs, or TEE attestations for high-stakes operations
- Cross-Chain Support: Works on any EVM-compatible chain including Celo
Why ERC-8004?
When AI agents interact across organizational boundaries, three critical questions arise:- Discovery: How do agents find each other? The Identity Registry provides searchable metadata—agents query the registry to discover other agents by capabilities, endpoints, or domain.
- Identity: How do agents verify who they’re dealing with? Each agent is an ERC-721 NFT with a cryptographically linked wallet, enabling verification that you’re communicating with the authentic agent owner.
- Trust: How do agents evaluate reliability? The Reputation Registry stores feedback from every interaction, creating a portable track record that travels with the agent across platforms.
Protocol stack
ERC-8004 fits into the broader agent infrastructure stack:The Three Registries
1. Identity Registry
Makes agents discoverable via portable NFT identifiers. Key capabilities:- Every agent identity is represented as an ERC-721 NFT—the agent itself runs off-chain, but its on-chain identity is an NFT that’s browsable in wallets, transferable between owners, and queryable by smart contracts
agentURIpoints to a registration file listing the service endpoints — see Register a service- Endpoint types are customizable —
web,A2A,MCP,OASF,ENS,DID,emailandwalletare examples, not a closed list register()sets the agent’s wallet to the address that sent the transaction; transferring the NFT clears it.setAgentWallet()changes it later, with a signature from the new wallet- Domain verification for endpoint ownership
2. Reputation Registry
Stores feedback and attestations about agent performance. Feedback is submitted on-chain by any address other than the agent’s own owner and operators, who are blocked from rating it. The contract does not check that the sender ever used the agent, so a raw summary can be padded — see Query Agent Reputation for reading one safely. In practice the addresses worth counting are users who hired the agent, other agents that collaborated with it, and monitoring services that track uptime. Common feedback tags:
Key functions:
giveFeedback()- Submit feedback with score and tagsrevokeFeedback()- Remove previous feedbackreadAllFeedback()- Get all feedback for an agentgetSummary()- Get aggregated reputation summary
3. Validation Registry
Independent verification hooks for high-stakes operations. Supported validation approaches:
Check out the repository of the ERC-8004 protocol for agent discovery and trust through reputation and validation.
Contract Deployments
Celo Mainnet
Celo Sepolia (Testnet)
Quick Start
Register a service
An identity is not limited to an autonomous agent that acts on its own. Any callable service — an HTTP API, an MCP server, a bot — can hold one. The service itself needs no on-chain logic: what it gets is a record agents can find and rate, with endpoints in the Identity Registry and feedback in the Reputation Registry. The registration file is JSON you host anywhere an agent can fetch it — any HTTPS URL, IPFS, or adata: URI stored on-chain; the spec does not mandate a path. services lists the endpoints you want callers to use. The names below are examples rather than a fixed set — the spec leaves the number and type of endpoints to you, and wallet entries for other chains are common. Set x402Support to true if those endpoints accept x402 payments.
registrations is what lets a caller check that the file and the on-chain entry agree, which is the cross-domain verification described above. You only learn the agent ID once the registration is mined, so the order is: publish the file without registrations, register, then update the file with the ID it returned. For an IPFS or data: URI, adding the ID changes the URI, so point the registry at the new one with setAgentURI(agentId, newURI).
Then point the registry at that file. Read the agent ID from the Registered event on the receipt — the value register() returns is _lastId at simulation time, so anyone else registering first makes it wrong:
setAgentURI(agentId, newURI), and set "active": false in the file when you retire the service. Transferring the agent NFT clears agentWallet, so the new owner sets it again. Gas for either call can be paid in a stablecoin — see fee abstraction.
Give Feedback
After interacting with an agent, submit feedback to the Reputation Registry.giveFeedback takes eight positional arguments, so the ABI below spells them out rather than compressing them into one signature string.
The contract blocks self-feedback: the agent’s owner and operators cannot rate their own agent, and the call reverts with Self-feedback not allowed. Feedback comes from a different address than the one that registered.
value is an int128, so scores can be negative, and valueDecimals (max 18) fixes the scale: 85 with 0 decimals is 85, 850 with 1 is also 85. feedbackHash is the keccak256 of the content at feedbackURI; with no URI there is nothing to hash, so pass zeroHash.
Query Agent Reputation
Before delegating work to an agent, read its reputation.getSummary aggregates, but it needs the list of addresses to aggregate over — fetch those with getClients first.
Two things decide whether the number you get back means anything. Pass a tag: an unfiltered summary averages every kind of feedback together, so a rating and an unrelated attestation end up in the same figure. And choose the addresses yourself where the decision matters: anyone can call giveFeedback, so a summary over every address that has ever rated an agent is open to padding. Treat getClients as a starting point, not an answer.
Use Cases
DeFi Trading Agents
This diagram shows a typical agent-to-agent interaction flow. A portfolio management agent needs to execute a trade, so it:- Queries the Identity Registry to discover available strategy agents
- Filters candidates using the Reputation Registry (checking track records, success rates)
- Selects an agent and requests a trade
- Pays for the service via x402 (HTTP-native payments)
- After the trade completes, submits feedback to build the strategy agent’s reputation
Multi-Agent Workflows
AI agents collaborating across organizations can:- Discover each other via Identity Registry
- Verify credentials before delegation
- Track performance with Reputation Registry
- Use Validation Registry for high-stakes decisions
Integration with Celo
ERC-8004 works seamlessly with Celo’s ecosystem:- Fee abstraction: Register agents and give feedback paying gas in stablecoins
- x402 payments: Combine trust verification with instant payments
- MCP servers: Agents can expose capabilities via Celo MCP Server
- Self Agent ID: A deployment of all three ERC-8004 registries on Celo that adds a zero-knowledge proof-of-human to each agent identity — see Self Agent ID
Resources
Related
- Self Agent ID - ERC-8004 registries with proof-of-human, live on Celo
- x402 - Payment layer for AI agents
- MPP - Machine Payments Protocol: charge USDC per request over HTTP
- Celopedia - Celo ecosystem knowledge for coding assistants
- MCP Servers - Connect agents to data and tools