All posts
· 10 min read ·

ERC-8004 admits identity isn't enough. The rest of the agent web hasn't caught up.

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.

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. The Identity Registry, the spec says, "connects identity to endpoints; it does not by itself prove that an agent fulfills its advertised capabilities." 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, roughly four months before this is being written. Davide Crapis, AI lead at the Ethereum Foundation, estimates one to two thousand builders 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:

ERC-8004's three-registry separation Three side-by-side columns labeled Identity, Reputation, and Validation. Each column shows what the registry stores at the top and what it proves at the bottom. The Identity column is rendered with a neutral border; Reputation in pink; Validation in violet. Together they illustrate the layered trust separation ERC-8004 makes explicit. ERC-8004 · THREE REGISTRIES, THREE QUESTIONS Identity STORES ERC-721 NFTs endpoints, metadata PROVES this identifier exists and points somewhere Reputation STORES client feedback, scores 0–100 PROVES others rated this agent at this score, this date Validation STORES zkML proofs, TEE attestations, stake PROVES an independent validator attested this check
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 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, 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. 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 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, 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

← Back to blog Agenstry