The Problem#
AI agents are starting to do real work — booking services, managing portfolios, coordinating tasks across organisations. But when two agents from different companies need to work together, there is no standard way for them to answer three basic questions:
- Who are you? — How does an agent prove its identity?
- Can I trust you? — How does an agent build (or lose) a reputation?
- Did you do the job right? — How does anyone verify an agent’s work?
ERC-8004 is a Draft ERC that answers these questions using Ethereum smart contracts. It gives AI agents — whether they speak MCP, A2A, or any other protocol — a shared trust layer that works across organisational boundaries without anyone needing to set up bilateral agreements in advance.
How It Works#
The standard defines three on-chain registries. Think of them as public, permissionless services that any agent can use on any EVM-compatible chain.
Identity — “Who are you?”#
Every agent gets an NFT that serves as its on-chain identity card. The NFT points to a registration file (hosted on IPFS, HTTPS, or embedded as a data URI) that describes:
- What the agent can do (capabilities, tools, skills)
- Which protocols it supports (MCP, A2A, etc.)
- Its wallet addresses, DIDs, and ENS names
Each agent has a globally unique identifier: {namespace}:{chainId}:{registryAddress}:{agentId}. Because identities are NFTs, they work out of the box with existing wallets, marketplaces, and block explorers.
| Method | What it does |
|---|---|
register() |
Create a new agent identity |
setAgentURI() |
Update the registration file |
setAgentWallet() |
Link an on-chain wallet to the agent |
getMetadata() / setMetadata() |
Read or write key-value metadata |
Reputation — “Can I trust you?”#
Anyone can leave public, structured feedback about an agent. Feedback is a numeric score (positive or negative) and can include tags, endpoint references, and supporting evidence files with integrity hashes.
Agents can respond to feedback, and clients can filter or weight reviewers however they choose — the registry stores the raw signals, not a single “star rating”.
| Method | What it does |
|---|---|
giveFeedback() |
Leave feedback about an agent |
revokeFeedback() |
Take back feedback you left |
appendResponse() |
Let the agent reply to feedback |
getSummary() |
Get an aggregate score for an agent |
readFeedback() |
Read individual feedback entries |
Validation — “Did you do the job right?”#
Sometimes reputation is not enough — you want an independent third party to verify a specific piece of work. The Validation Registry provides generic hooks for requesting and recording these checks.
Validators score work on a 0–100 scale, which can be interpreted as pass/fail or as a spectrum. The standard deliberately does not prescribe how validation happens — implementations might use re-execution secured by staked collateral, zero-knowledge proofs, trusted hardware attestations, or human judges.
| Method | What it does |
|---|---|
validationRequest() |
Ask for work to be validated |
validationResponse() |
Submit a validation result |
getValidationStatus() |
Check if validation is pending or done |
getSummary() |
Get an aggregate of validation results |
Why These Design Choices?#
- Agents as NFTs — reuses the massive existing ecosystem of wallets, explorers, and tooling rather than inventing new infrastructure.
- Off-chain registration file — keeps the on-chain footprint small while still linking to rich descriptions of an agent’s capabilities.
- Protocol-agnostic — borrows terminology from both A2A (tasks, skills) and MCP (tools, prompts) so the standard is not locked to a single agent framework.
- Account abstraction friendly — enables gas-sponsored transactions so that leaving feedback does not require the reviewer to hold ETH.
What It Builds On#
| Standard | Why it is needed |
|---|---|
| EIP-155 | Includes chain ID in agent identifiers to avoid collisions across networks |
| EIP-712 | Enables readable, typed signatures for off-chain messages |
| ERC-721 | Provides the NFT base for agent identities |
| EIP-1271 | Lets smart-contract wallets (not just EOAs) sign on behalf of agents |
Open Risks#
- Fake agents gaming reputation — colluding agents can leave each other glowing reviews. The data is public so clients can build filters, but the protocol itself does not prevent Sybil attacks.
- Agents lying about what they do — registering a capability does not prove an agent actually has it. The three trust layers (reputation, validation, hardware attestation) are defences in depth, not guarantees.
- Validator incentives are left to implementers — the standard does not define slashing or rewards; each validation protocol must design its own economics.
Resources#
- ERC-8004 specification
- Discussion on Ethereum Magicians
- awesome-erc8004 — community resource list