What Is ERC-8004? The Ethereum Standard Giving AI Agents an On-Chain ID — and What It Still Can't Verify

Of ERC-8004's three registries, the Identity Registry is foundational to nearly every scenario, but the Reputation and Validation Registries are "optional" — in practice, when is identity alone not enough?

The problem the Identity Registry solves is fundamentally "who is this agent, and can it be found" — like a business card, it proves existence, not competence or reliability. When transaction amounts are small and risk is contained (a few cents per API call, say), the Identity Registry alone, combined with the basic observation that "this same identity has interacted many times without incident," might be sufficient.

But when you're delegating an agent to execute a strategy involving real money, or an agent claims some specific capability ("I can do cross-chain Arbitrage," "my win rate is 80%"), mere existence of an identity does nothing to corroborate whether those claims are true. That's where the Reputation Registry can offer "how have other parties rated this agent in the past," and the Validation Registry can offer "has an independent third party verified, in some checkable way, that this agent actually did what it claims." The larger the amount and the more specific the claim, the higher the level of corroboration you should require — the Identity Registry was never designed to answer "is this agent trustworthy" in the first place.

Why did ERC-8004 choose a modular "three independent registries" design instead of a single integrated "Agent Trust Score" system?

The logic behind the modular design is an acknowledgment that trust isn't a single-dimensional problem — different scenarios need entirely different kinds of trust evidence, and forcing them all into one score would actually obscure important distinctions. For example, one agent might have a long identity registration history (indicating stable existence) but almost no reputation record (indicating it's rarely interacted with or rated); another agent might have a high reputation score, but all those ratings come from the same handful of accounts (indicating the score's credibility is questionable). Compress that into a single number and you lose the ability to tell these two very different situations apart.

Modularity also lets different scenarios flexibly combine verification strength: a low-risk, small-value interaction might only need to check the Identity Registry; a high-risk, large-value delegation could require both a positive feedback history in the Reputation Registry and independent technical corroboration in the Validation Registry. This design leaves the judgment of "how strict a standard should be used to trust this agent" to the party actually making the transaction, rather than having the protocol itself preset a one-size-fits-all trust threshold.

How would you actually detect inflated or review-washed ratings in the Reputation Registry? Are there concrete ways to check?

The most direct method is checking the dispersion of rating sources: a healthy reputation record should have scores coming from multiple accounts spread across time, with no obvious connection between them. If most ratings appear within an extremely short time window, or the rating accounts themselves are newly registered with almost no other interaction history, that's a classic sign of inflated reviews. This is the same logic used to spot fake reviews in any online rating system — except on-chain, these accounts' registration times and interaction histories are publicly checkable, without relying on a platform's willingness to disclose them.

Another cross-checkable signal is whether the Reputation Registry's positive ratings align with independent corroboration in the Validation Registry. If an agent has abundant positive ratings but zero independent technical verification of any kind, and the capability it claims is the type that's actually easy to verify ("I executed this specific on-chain transaction"), that gap between "rated but unverified" is itself worth flagging. The ERC-8004 empirical study also notes that the Validation Registry has seen almost no practical use on mainnet to date, which means the ecosystem's current reliance on the Reputation Registry is, to some extent, higher than what the system was originally designed to depend on.

If I'm a developer building a DeFAI agent and want it registered on ERC-8004, what should I consider in practice? What's actually different compared to skipping the standard entirely?

The direct difference is discoverability and portability. Without registering on ERC-8004, your agent can only be found and trusted within whatever platform or ecosystem you built it in — any cross-platform collaboration or transaction requires rebuilding a trust mechanism from scratch. After registering with ERC-8004, your agent has an identity that can be recognized and queried by any other system following the same standard, opening up the theoretical possibility of cross-organizational collaboration without having to individually negotiate trust with every potential counterparty in advance.

But worth noting: registration alone only opens the door to being discoverable. The record in the Reputation Registry has to build up gradually through real interactions — you don't automatically have a reputation just by registering. And whether to attach additional corroboration through the Validation Registry is a cost consideration: building verifiable proof of execution (like a zero-knowledge machine-learning proof) carries real engineering cost, and whether it's worth investing depends on how much your target users actually care about independent verification. If your target market is fine deciding purely off a reputation score, an extra verification layer might not be your priority. If you're courting the more cautious users this article discusses — the ones who actually check the dispersion of reputation sources — independent verification is exactly where it's worth investing first.