ERC-8004's three-registry separation

--- title: "ERC-8004 admits identity isn't enough. The rest of the agent web hasn't caught up." date: 2026-05-18 summary: "ERC-8004's most architecturally honest sentence is in the EIP itself: identity registration does not prove capability. The standard then designs around that admission with three separate registries. Most agent registries hold the same property without naming it." slug: erc-8004-three-registries-honesty author: "Sebastiaan Hilbers" hero_glyph: rings --- The most architecturally honest sentence in any agent-registry standard currently in production was written by Marco De Rossi, Davide Crapis, Jordan Ellis, and Erik Reppel in [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004). The Identity Registry, the spec says, ["connects identity to endpoints; it does not by itself prove that an agent fulfills its advertised capabilities."](https://composable-security.com/blog/erc-8004-a-practical-explainer-for-trustless-agents/) Most other registries in the agent space hold the same property and decline to name it. ERC-8004 names it and then designs around it. The registry standard went live on Ethereum mainnet on [January 29, 2026](https://eco.com/support/en/articles/13221214-what-is-erc-8004-the-ethereum-standard-enabling-trustless-ai-agents), roughly four months before this is being written. Davide Crapis, AI lead at the Ethereum Foundation, [estimates one to two thousand builders](https://composable-security.com/blog/erc-8004-a-practical-explainer-for-trustless-agents/) have joined development groups since the EIP was first published in August 2025. The number that matters is not the registration count. It's the shape of the registry the spec proposes. ## Three registries, not one ERC-8004 separates what most agent registries conflate. There is an Identity Registry, a Reputation Registry, and a Validation Registry — three distinct objects with three distinct verification properties: | Registry | What it stores | What a consumer learns | What it does not prove | |---|---|---|---| | Identity | ERC-721 NFTs with agent metadata, endpoints, services | This identifier exists, points to these endpoints, and is owned by this key | That the endpoint responds, behaves correctly, or matches the metadata | | Reputation | Client feedback signals, scores 0–100, optional tags, off-chain detail links | Other parties have rated this agent at this score on this date | Whether the raters are independent, honest, or representative | | Validation | Validator-supplied verification using zkML proofs, stake-secured re-execution, or TEE oracles | An independent validator has attested to a specific check at a specific time | Whether the validator is competent or honest, beyond the staking incentive | The structure is deliberate. A consumer who wants high assurance about a specific agent reads all three. A consumer who only needs a stable identifier reads only the Identity Registry. The registry pattern most agent-web infrastructure has shipped so far (one schema, one publication, one number) collapses all three into a single object and then has to explain in prose why that one object is not a trust signal. ERC-8004 makes the explanation structural instead. ## What the spec deliberately leaves to operators [The Composable Security explainer](https://composable-security.com/blog/erc-8004-a-practical-explainer-for-trustless-agents/) catalogues what ERC-8004 intentionally does not specify, and the list is worth reading as a separate design feature: - **Economic parameters.** Collateral amounts, reward structures, and slashing rules are not specified. A validation registry that requires staking is only as good as the stake size, slashing rules, and reward function chosen by the deployment. The spec declines to choose for you. - **A single reputation formula.** Aggregation across the Reputation Registry's raw feedback is left to off-chain services. The spec explicitly does not pick a weighting scheme, anti-Sybil filter, or recency function. - **Sybil resistance.** The same source notes that "many identities can still exist" despite the pre-authorized feedback mechanism, requiring "downstream filtering and weighting strategies." The Identity Registry is permissive by design; resistance happens above it. - **Operational controls.** "Production deployments also need operational controls appropriate to the value at risk." Translation: the registry is a primitive, not a complete trust system, and the spec wants you to remember that. Each of those omissions is structurally analogous to a TLS certificate authority leaving certificate issuance policy to its subscribers — the substrate provides the primitive; the policy is delegation done deliberately. The difference is that the EIP writes the delegation down. ## What this template asks of the rest of the agent web The contrast with adjacent agent-registry efforts is instructive. The [Linux Foundation MCP Registry](https://github.com/modelcontextprotocol/registry), the public discovery layer for MCP servers, currently combines self-declared metadata with no separate reputation surface, no validation surface, and no signing requirement at the registry level. A consumer reading the MCP Registry sees one object per server. They do not see three. The same shape appears in [A2A's Signed Agent Cards](https://a2a-protocol.org/latest/specification/). The signature binds a card to a key, which is structurally what ERC-8004's Identity Registry does. There is no Reputation analogue in A2A and no Validation analogue. A2A's design choice is defensible (a protocol can sensibly leave higher-tier trust signals to other layers), but the gap between what a Signed Agent Card proves and what a consumer needs in order to trust an agent is the same gap ERC-8004 names in its own spec text. The argument here is not that MCP or A2A should ship a Reputation Registry. The argument is that ERC-8004 has shown a way to be honest in the design about which trust signals the spec carries and which it doesn't. A consumer reading an MCP server entry today does not have the benefit of that honesty. They have to infer it. [Agenstry's registry](https://agenstry.com) operates on the same implicit three-tier model that ERC-8004 makes explicit. The Identity analog is the server's published card. The Reputation analog is the funnel data we publish about how many agents respond and conform across the population. The Validation analog is the probe results attached to each agent. The three sit in three different columns on the page for the same reason the EIP put them in three different registries: a consumer needs to know which signal they are reading. ## What we're watching Three things, observable within the next two quarters: 1. **Whether the AAIF MCP Registry roadmap adopts a separation of identity, reputation, and validation surfaces.** The most useful change would not be moving to on-chain storage (that's a different debate) but adopting the *structure*: separate registers for what an author claims, what consumers report, and what independent probes attest. 2. **Whether the first specialized ERC-8004 validator networks come online for narrow verticals.** The EIP imagines per-vertical validators (DeFi, healthcare, legal). The first one to publish stake amounts, slashing parameters, and live attestations will be a useful data point for how the validation model performs under economic incentive. 3. **Whether MCP's hosted registry and ERC-8004's on-chain identity register converge into a single addressable identity.** [ERC-8004 already lists MCP among its supported protocols](https://learn.backpack.exchange/articles/erc-8004-explained), but there is no specified handshake by which an MCP server's published card and its ERC-8004 anchor mutually verify. A registered convention for that handshake would let consumers treat the two ecosystems as one identity surface. ERC-8004 is not a competitor to MCP, AAIF, or A2A. It is an unrelated substrate that happens to model the same problem with one more degree of honesty. The other registries can keep their architecture and import the spec's structural admission: an identity is not a trust claim, a reputation is not a behavior claim, and a validation is not a correctness claim. They are three different objects, and the consumers that depend on them deserve to be told which is which. ## Sources - [ERC-8004: Trustless Agents](https://eips.ethereum.org/EIPS/eip-8004) — Marco De Rossi, Davide Crapis, Jordan Ellis, Erik Reppel, Ethereum Improvement Proposals, August 13, 2025. - [ERC-8004: a practical explainer for trustless agents](https://composable-security.com/blog/erc-8004-a-practical-explainer-for-trustless-agents/) — Composable Security, 2026. - [What is ERC-8004? The Ethereum Standard Enabling Trustless AI Agents](https://eco.com/support/en/articles/13221214-what-is-erc-8004-the-ethereum-standard-enabling-trustless-ai-agents) — Eco.com Support, 2026. - [Model Context Protocol Registry repository](https://github.com/modelcontextprotocol/registry) — modelcontextprotocol/registry, accessed May 2026. - [Agent2Agent (A2A) Protocol Specification](https://a2a-protocol.org/latest/specification/) — A2A Protocol, accessed May 2026. - [ERC-8004 Explained](https://learn.backpack.exchange/articles/erc-8004-explained) — Backpack Exchange Learn, 2026.