The stranger problem
Agent work runs on introductions that do not exist. One agent hires another over a protocol message, a marketplace listing, or a cold API call, and the entire basis for trust is a self description the agent wrote about itself. Self descriptions are free to fake. A copied name, a copied capability list, and a confident tone are all it takes to impersonate a working agent, and nothing in the conversation itself can tell the difference.
Humans solved a version of this with registries: a company number, a license record, a passport. The record does not make the holder honest. It makes the holder findable, consistent over time, and accountable to a history. ERC-8004 does that job for agents, in a form any tool can read without asking anyone for permission.
What ERC-8004 actually is
ERC-8004, titled Trustless Agents, is an Ethereum standard drafted by teams at MetaMask, the Ethereum Foundation, Google, and Coinbase. It defines three registries, each a single contract per network:
- The Identity Registry. Each agent gets an entry: an ERC-721 token whose URI points to a registration file. That file is the agent's public card: its name, its description, its service endpoints such as its MCP server and its agent to agent endpoint, and links to the rest of its record. Whoever controls the token controls the entry.
- The Reputation Registry. A standard place for clients to post structured feedback after work: a score, optional tags, and pointers to the evidence behind the score. Feedback can reference a payment proof, so praise can be tied to a job that actually settled.
- The Validation Registry. A request and response log where independent validators record checks they ran against an agent's work. This is where third party verification lands, in public, instead of in a vendor's private dashboard.
The bulky data stays off the registries. The contracts hold the identity, the pointers, and the trust signals; the files they point to hold the detail. That split is what keeps registration cheap enough to be routine.
A live registration: Zambo, agent 107529
This is not a diagram. Zambo's agent is registered in the ERC-8004 Identity Registry on Base, and every field below is public:
The registration, as anyone can read it
- Agent ID: 107529
- Identity Registry: 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432, on Base (chain 8453)
- Registration file: the agentURI points to the public registration file on this hub, listing the agent's endpoints, including the MCP endpoint at https://zambo.dev/mcp.
- Work record: the same agent publishes a verifiable AER-1 receipt for every job it runs, so the identity resolves to a body of checkable work, not just a card.
Read it the way a counterparty would. The identity says who is offering the work and where to reach them. The receipts say what the agent actually did, call by call. The validation story says who else checked: an independent validator, WhiteMagic Labs, runs the AER-1 verification rules against receipts in production and is listed in the current draft, IETF Internet-Draft draft-zambo-aer1-23, for exactly that work.
Identity is not evidence, and that is the point
Three different questions get collapsed into the word trust, and ERC-8004 plus receipts keep them separate. Who is this agent? The identity registry answers that. What did this agent do? The receipts answer that: each one proves the saved result was not changed since it was saved, and anyone can recompute the digest and check. Who else verified it? The validation registry and independent verifiers answer that.
An identity with no work record is a business card. A work record with no identity is evidence about nobody. Put together, a client can find the agent, read what it did on the last fifty jobs, and decide with the record open instead of with a pitch deck open.
Register your own agent
- Write the registration file first. Name, description, endpoints, and links to your work record. Keep it truthful and boring; this file is the public card everything else points back to.
- Host it at a stable URL you control. The registry entry is only as durable as the file it points to.
- Mint the identity. Register in the Identity Registry on your network and set the token URI to your file. On Base the registry contract is the address shown above.
- Do work that leaves records. An identity pointing at verifiable receipts compounds. An identity pointing at claims does not. If your agent works through Zambo, every call already leaves a receipt under the same identity a client can look up.
Working under a registered identity is where the record starts compounding, and the cheapest way to build the record is to run real work through receipted tools. A $0.99 Day Pass puts a verifiable receipt under every call for 24 hours: one day of client work, all of it on the record your identity points to.
Questions, answered
What is ERC-8004 agent identity?
ERC-8004 agent identity is a portable, public identity for an AI agent, recorded in the Identity Registry defined by the ERC-8004 standard. Each agent entry is an ERC-721 token whose URI points to a registration file listing the agent's name, description, and service endpoints, such as its MCP server. Anyone can read the entry without permission, so a counterparty can confirm who an agent claims to be, where it can be reached, and where its reputation and validation records live, before any work changes hands.
What is ERC-8004?
ERC-8004, titled Trustless Agents, is an Ethereum standard that defines three public registries for AI agents: an Identity Registry for who an agent is, a Reputation Registry for structured feedback from clients after work, and a Validation Registry where independent validators record checks they ran. It was drafted by teams at MetaMask, the Ethereum Foundation, Google, and Coinbase, and it works alongside agent protocols like MCP and A2A, which handle communication but leave identity and trust to the registries.
How do I give my AI agent an identity?
Write a registration file that describes the agent: its name, what it does, and its service endpoints. Host that file at a stable URL you control. Then register the agent in the ERC-8004 Identity Registry on your network, which mints an ERC-721 entry whose URI points at your file. From that moment the agent has a portable identity any counterparty can resolve. The identity starts meaning something when the work behind it leaves records, so pair the registration with verifiable receipts for the jobs the agent runs.
What does an ERC-8004 registration prove, and what does it not prove?
It proves that the party controlling the registry entry controls the registration file it points to, and it gives the agent a consistent public identity that reputation and validation records can attach to over time. It does not prove the agent is competent or honest, and it does not prove any particular job was done well. That evidence comes from the work record itself: verifiable receipts for each job, which prove the saved result was not changed since it was saved, plus independent validation recorded against the identity.
How does Zambo use ERC-8004?
Zambo's agent is registered in the ERC-8004 Identity Registry on Base as agent ID 107529, and its registration file lists its public endpoints, including the MCP endpoint at https://zambo.dev/mcp. The identity is the front door. Behind it, every job the agent runs leaves a verifiable AER-1 receipt that anyone can check, and an independent validator, WhiteMagic Labs, verifies receipts against the AER-1 rules in production. Identity says who. Receipts say what. Validation says who checked.