# ERC-8004: Building a Trust Layer for AI Agents Onchain > ERC-8004 gives AI agents verifiable identity, reputation, and validation on Ethereum. Here's what the standard actually defines, why it matters, and where it's headed. - Published: 2026-03-20 - Tags: web3, ethereum, ai, protocols, standards - URL: https://www.woza.ink/blog/erc-8004-trustless-agents AI agents can talk to each other. Protocols like Google's A2A and Anthropic's MCP handle communication and tool use. What they don't handle is trust. When your agent encounters a stranger agent on the open internet — one it's never seen before, operated by someone it has no relationship with — how does it decide whether to interact? How does it verify that agent is who it claims to be? How does it check its track record? ERC-8004, titled **Trustless Agents**, is an Ethereum standard that answers those three questions with three onchain registries: Identity, Reputation, and Validation. It doesn't replace A2A or MCP — it gives them a trust layer they don't have. > Note: ERC-8004 is currently in **Draft** status. The spec is actively evolving, with significant community input from Consensys, Ethereum Foundation, Coinbase, and Google contributors. What's described here reflects the standard as of March 2026. --- ## TL;DR - Three registries: Identity (who are you?), Reputation (what's your track record?), Validation (can a third party verify your work?) - Agent identity is an ERC-721 NFT — transferable, composable, works with existing wallet infrastructure - Heavy data stays off-chain via URIs with KECCAK-256 hash commitments; only the trust primitives live onchain - Deliberately excludes payment mechanisms, reputation formulas, and specific validation methods — those are left to other protocols - Deployed on Ethereum mainnet and 30+ EVM chains since January 2026, with 45,000+ registered agents --- ## The problem: communication without trust MCP lets an agent use tools. A2A lets agents talk to each other. Neither answers the fundamental question of an open, permissionless network: **should I trust this agent?** In a closed system — agents within the same company, or agents from pre-approved partners — trust is inherited from the organizational relationship. You trust your own agents because you deployed them. You trust your partner's agents because you signed a contract with the partner. In an open system, none of that exists. An agent advertising a service could be competent, incompetent, or actively malicious. There's no organizational hierarchy to fall back on. The agent might claim to be a financial advisor, a code reviewer, or a data analyst — but claims are cheap. ERC-8004 provides three primitives that let agents establish trust without pre-existing relationships: 1. **Identity**: a verifiable, onchain record of who an agent is 2. **Reputation**: a history of what other agents think of its work 3. **Validation**: independent third-party verification of its outputs Each is a separate smart contract registry. Each is minimal by design. The standard defines the interfaces; it doesn't dictate how you interpret the data. --- ## Identity Registry: agents as NFTs The Identity Registry extends ERC-721. When an agent registers, it gets an NFT — a unique onchain identity that's transferable, composable with existing Ethereum tooling, and owned by the address that minted it. ```solidity function register( string agentURI, MetadataEntry[] calldata metadata ) external returns (uint256 agentId); ``` The `agentURI` points to an off-chain JSON file — the Agent Registration File — that describes the agent: its name, description, services it offers, and endpoints for protocols like A2A, MCP, or OASF. The URI can point to IPFS, Arweave, or a traditional HTTPS endpoint. What matters is that the onchain record commits to the content via hash. Agents can store key-value metadata onchain: ```solidity function setMetadata( uint256 agentId, string metadataKey, bytes metadataValue ) external; ``` One reserved metadata key is `agentWallet` — the payment address for the agent. Setting it requires an EIP-712 or EIP-1271 signature, which means the wallet address must actively consent to being associated with the agent. This prevents impersonation: you can't point your agent's payment address at someone else's wallet without their signature. The global identifier format is `eip155:{chainId}:{identityRegistry}`, which makes agent identity chain-aware and interoperable across EVM networks. **Why NFTs?** Because the entire ERC-721 ecosystem already exists. Agents can be transferred between owners, listed on marketplaces, held by multisigs, governed by DAOs, or used as collateral. Every wallet, explorer, and indexer already knows how to handle them. The standard gets composability for free. --- ## Reputation Registry: structured feedback at scale After interacting with an agent, a client can leave structured feedback onchain: ```solidity function giveFeedback( uint256 agentId, int128 value, uint8 valueDecimals, string tag1, string tag2, string endpoint, string feedbackURI, bytes32 feedbackHash ) external; ``` This isn't a five-star review system. The `value` field is a signed 128-bit integer with configurable decimal precision. The `tag1` and `tag2` fields categorize the feedback — `starred` for general quality, `reachable` for endpoint liveness, `uptime` for availability, `tradingYield` with a time period as `tag2`. The `feedbackURI` links to detailed off-chain feedback data, committed with a hash. Agents can respond to feedback: ```solidity function appendResponse( uint256 agentId, address clientAddress, uint64 feedbackIndex, string responseURI, bytes32 responseHash ) external; ``` And clients can revoke feedback if circumstances change. The registry also provides aggregation: ```solidity function getSummary( uint256 agentId, address[] clientAddresses, string tag1, string tag2 ) external view returns ( uint64 count, int128 summaryValue, uint8 summaryValueDecimals ); ``` **What the standard intentionally doesn't do**: it doesn't define a reputation *formula*. It doesn't say "agents with score > X are trustworthy." That's a deliberate choice. Different applications need different trust models. A DeFi protocol might weight recent trading performance heavily. A code review service might care about long-term consistency. A data pipeline might only care about uptime. The registry provides the raw data; interpretation is left to the consumer. --- ## Validation Registry: third-party verification The Validation Registry handles cases where you want an independent party to verify an agent's work — not just client opinions, but cryptographic or computational proof. ```solidity function validationRequest( address validatorAddress, uint256 agentId, string requestURI, bytes32 requestHash ) external; function validationResponse( bytes32 requestHash, uint8 response, string responseURI, bytes32 responseHash, string tag ) external; ``` The `response` is a 0-100 scale (0 = failed, 100 = passed). The `tag` categorizes the type of validation. This registry is intentionally generic because the standard supports multiple validation approaches: - **Crypto-economic validation**: stakers re-execute an agent's task and are slashed if they attest dishonestly - **zkML proofs**: zero-knowledge proofs that an ML model produced a specific output for a specific input — cryptographic proof of correct inference - **TEE attestation**: Trusted Execution Environment attestations (Intel SGX/TDX) proving code ran in a secure enclave The registry doesn't care which mechanism you use. It provides the interface for recording that validation happened and what the result was. --- ## Design philosophy: minimal onchain surface ERC-8004 is opinionated about what it *excludes*: - **No payment mechanism.** Protocols like x402 or direct ERC-20 transfers handle payments. The standard only stores the agent's wallet address. - **No reputation algorithm.** The registry stores raw feedback. How you interpret it is your problem. - **No mandated validation method.** zkML, TEE, staking — use whatever fits your threat model. - **No heavy data onchain.** URIs point to off-chain data; KECCAK-256 hashes commit to integrity. The onchain footprint stays small. This minimalism is the point. The standard provides the thinnest viable trust layer — just enough to let heterogeneous systems compose. A Solidity contract, a Python script, and a browser extension can all query the same registries and make their own trust decisions. --- ## Who's behind it The authors list includes Marco De Rossi (MetaMask/Consensys), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google), and Erik Reppel (Coinbase). The broader contributor list includes people from ENS, EigenLayer, The Graph, and others — reportedly 100+ industry contributors shaped the spec. That cross-organizational authorship matters. An agent trust standard only works if it's not owned by any single platform. The fact that MetaMask, EF, Google, and Coinbase are all at the table suggests this isn't a proprietary play dressed as a standard. --- ## Current state and adoption ERC-8004 contracts were deployed to Ethereum mainnet on January 29, 2026, using CREATE2 for deterministic addresses across 30+ EVM chains: - **IdentityRegistry**: `0x8004A169FB4a3325136EB29fA0ceB6D2e539a432` - **ReputationRegistry**: `0x8004BAa17C55a88189AE136b182e5fdA19dE9b63` As of early 2026, over 45,000 agents have been registered across these chains. Notable implementations include Phala Network (TEE-based agents), Vistara Agent Arena (CrewAI demo), and AgentStore (marketplace using ERC-8004 identity with x402 payments). The spec itself has had an interesting status journey: it moved from Draft to Review in October 2025, then back to Draft in January 2026 — likely because community feedback warranted significant changes. Multiple companion ERCs have been proposed: multichain agent relationships, zero-knowledge payment verification, agent subscriptions, and agentic commerce extensions. --- ## What I think ERC-8004 is solving a real problem at the right layer. The agent communication protocols (MCP, A2A) are necessary but not sufficient — they give agents a language without giving them judgment. If the agentic economy is going to be more than agents talking to pre-approved partners inside walled gardens, something like this has to exist. The NFT-based identity is clever. Not because agents need to be traded on OpenSea, but because it makes agent identity immediately composable with every tool Ethereum already has — wallets, multisigs, governance, indexers. That's a lot of infrastructure you don't have to rebuild. The deliberate minimalism is the strongest design choice. A standard that tried to define *the* reputation algorithm or *the* validation method would be dead on arrival — different applications need different trust models. By providing only the raw primitives, ERC-8004 stays useful across use cases without prescribing solutions. The open question is adoption velocity. 45,000 registered agents sounds impressive, but the real test is whether agents are actually *querying* these registries before making trust decisions, or whether registration is just a checkbox. The reputation and validation registries are where the value lives, and they're only useful if populated with meaningful data. The spec is still in Draft. It's moving fast, and the interfaces may shift. But the core insight — that open agent networks need onchain trust primitives the same way the web needed DNS and TLS — feels right. Whether ERC-8004 becomes *the* standard or just the first serious attempt, the problem it's addressing isn't going away. --- ## Links - [ERC-8004 spec](https://eips.ethereum.org/EIPS/eip-8004) - [Ethereum Magicians discussion](https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098) - [Official contracts repo](https://github.com/erc-8004/erc-8004-contracts) - [Awesome ERC-8004](https://github.com/sudeepb02/awesome-erc8004) *Related reading: [Exploring the x402 Standard](https://www.woza.ink/blog/exploring-x402-standard) — the payment protocol several ERC-8004 implementations are pairing with for agent commerce.* ## Notes 1. **source** on "Protocols like Google's A2A and Anthropic's MCP handle communication and tool use": Google's **Agent2Agent (A2A)** protocol was introduced in April 2025 and later donated to the Linux Foundation. It defines Agent Cards (JSON capability advertisements), task lifecycle management, and communication over HTTPS with JSON-RPC 2.0. Anthropic's **MCP** (Model Context Protocol), launched November 2024, provides the tool-use layer with three primitives: tools (model-controlled), resources (app-controlled), and prompts (user-controlled). ERC-8004 explicitly positions itself as a trust layer that sits beneath both. (https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) 2. **quote** on "How does it verify that agent is who it claims to be? How does it check its track record": McKinsey research shows that **80% of organizations** have encountered risky behavior from AI agents. Galileo AI found that a single compromised agent can poison 87% of downstream decision-making within 4 hours through cascading failures. The trust problem is not theoretical — it is the top operational risk in multi-agent systems. (https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/trust-in-the-age-of-agents) 3. **context** on "When an agent registers, it gets an NFT — a unique onchain identity": The W3C's **Decentralized Identifiers (DIDs)** and **Verifiable Credentials (VCs)** are the established prior art for self-sovereign identity. A 2025 arXiv paper proposed equipping AI agents with DID-anchored identities and VCs for autonomous trust establishment. ERC-8004 takes a different approach — using ERC-721 NFTs instead of DIDs — which trades W3C interoperability for deep composability with the existing Ethereum ecosystem (wallets, marketplaces, multisigs, DAOs). (https://arxiv.org/abs/2511.02841) 4. **note** on "Every wallet, explorer, and indexer already knows how to handle them": **ERC-6551** (Token Bound Accounts) could complement ERC-8004 by giving each agent identity NFT its own smart contract wallet. This means an agent's identity and its wallet become a single composable unit — the NFT *is* the agent, and the token-bound account *is* its treasury. Several community proposals explore this pairing. 5. **counter** on "it doesn't define a reputation formula. It doesn't say "agents with score > X are trustworthy."": The deliberate absence of a reputation formula is both ERC-8004's greatest strength and its biggest risk. Without a standard scoring mechanism, every consumer must implement their own trust model — which means early adopters may end up with incompatible interpretations of the same data. The Ethereum Magicians discussion thread shows active debate on whether a minimal "recommended" algorithm should be included as a non-normative appendix. (https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098) 6. **context** on "the standard supports multiple validation approaches": The three validation approaches mentioned (crypto-economic, zkML, TEE) represent different points on the trust-cost spectrum. **Crypto-economic validation** (stakers re-execute tasks) is cheapest but slowest. **zkML proofs** are cryptographically rigorous but computationally expensive to generate. **TEE attestation** (Intel SGX/TDX) offers real-time verification but requires hardware trust assumptions. The registry's agnosticism lets applications pick the right tradeoff. 7. **source** on "The authors list includes Marco De Rossi (MetaMask/Consensys), Davide Crapis (Ethereum Foundation)": The ERC-8004 spec was first published as a draft in **August 2025**, moved to Review in October 2025, then reverted to Draft in January 2026 after community feedback warranted significant changes. The contracts were deployed to mainnet on January 29, 2026 using CREATE2 for deterministic addresses across 30+ EVM chains. Over 100 industry contributors shaped the spec, including representatives from ENS, EigenLayer, and The Graph. (https://eips.ethereum.org/EIPS/eip-8004) 8. **quote** on "open agent networks need onchain trust primitives the same way the web needed DNS and TLS": "AI went from assistant to autonomous actor, and security never caught up." Autonomous agents now outnumber humans 82:1 in the average enterprise, and OWASP's 2025 LLM Top 10 ranks prompt injection as the #1 risk. ERC-8004's bet is that onchain trust primitives can provide the verification layer that centralized identity systems cannot — because in a permissionless network, there is no central authority to vouch for anyone. (https://www.helpnetsecurity.com/2026/03/03/enterprise-ai-agent-security-2026/)