ERC-8004: Trustless Agents
ERC-8004 is a Draft ERC defining three on-chain registries — identity, reputation, and validation — that give AI agents a shared trust layer across organisational boundaries, with no bilateral agreement arranged in advance. It is protocol-agnostic: an agent speaking MCP, A2A (agent-to-agent), or anything else uses the same registries.
The three questions#
Agents from different companies that need to work together have no standard way to settle three things, and one registry answers each:
- 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?
How It Works#
The registries are public and permissionless, deployed on any EVM-compatible chain, and callable by any agent.
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 Ethereum Name Service (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() |
Withdraw feedback previously 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?”#
Reputation aggregates opinions after the fact; some work needs an independent third party to check the output itself. The Validation Registry provides generic hooks for requesting and recording those 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 — an agent identity shows up in existing wallets, explorers, and marketplaces with no new infrastructure, and transfers with the same call as any other token.
- 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 externally owned accounts) 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