You're Reading ERC-8004 Wrong

Published: February 17, 2026 | 12 min read

Everyone is calling ERC-8004 "the agent standard." The crypto media ran with it. X (Twitter) ran with it. Even some of the builders in the ecosystem ran with it.

And they're all reading the title instead of the spec.

ERC-8004 is titled "Trustless Agents," but the standard itself is not limited to agents. Today, it's not even primarily about agents. It's a general-purpose trust and discovery infrastructure for the machine economy, and the sooner people understand that, the sooner they'll start building the things that actually matter on top of it.

What People Think ERC-8004 Is

The popular narrative goes something like this: AI agents are coming, they'll need to transact with each other on-chain, and ERC-8004 gives them identity, reputation, and validation. It's "ERC-20 for agents." The end.

This framing is neat, marketable, and wrong in a way that matters. It boxes the standard into one use case: autonomous AI agents talking to other autonomous AI agents, while ignoring the fact that the spec was deliberately designed to be much broader.

What the Spec Actually Says

Open the actual EIP and read the abstract:

Now read the motivation section. It names both MCP (Model Context Protocol) and A2A (Agent-to-Agent) as the protocols it's extending with a trust layer.

This is important: MCP servers are often not agents at all. They're tool providers. A database connector, a code execution sandbox, a weather API wrapped in MCP—these are services, not agents. ERC-8004 explicitly positions itself as the discovery and trust layer for them too.

The Registration File Structure

Look at the services array. It accepts:

• A2A endpoints — yes, for agents
• MCP endpoints — for tool servers and capability providers
• Plain web URLs — for any HTTP service
• ENS names — for on-chain identity resolution
• DIDs — for decentralized identity
• OASF endpoints — for agent framework interop
• Email addresses — yes, literally email

This isn't an agent registry. It's a universal service registry with a flexible identity layer built on ERC-721.

The Three Registries Are Generic Primitives

Let's look at each registry without the "agent" goggles on.

Identity Registry

An ERC-721 token whose URI points to a registration file. The registration file describes what something is, what it does, and where to reach it.

Nothing in this design requires the registered entity to be an AI agent. An oracle network could register. A DeFi protocol's automated liquidation service could register. A data provider could register. An MCP tool server could register.

The supportedTrust field is optional—if you leave it empty, the spec says you're using ERC-8004 purely for discovery. That's a decentralized service directory, plain and simple.

Reputation Registry

The feedback system uses a generic value/valueDecimals pair with optional tags. Look at the example metrics the spec itself provides:

• reachable — is the endpoint up?
• uptime — endpoint uptime percentage
• responseTime — response time in milliseconds
• successRate — endpoint success rate
• blocktimeFreshness — average block delay
• revenues — cumulative revenues
• tradingYield — yield over a time period

Half of these are infrastructure metrics. reachable, uptime, responseTime—you'd track these for any API, any oracle, any service.

This is not a "how good is this AI agent" system. It's a general-purpose, on-chain reputation primitive that works for anything with an endpoint.

Validation Registry

The validation system lets any registered entity request verification of its work, and any validator smart contract can respond. The verification mechanisms listed—"stake-secured re-execution, zkML proofs, TEE oracles"—are general computation verification techniques.

They apply to any service that produces outputs someone might want to verify: an oracle providing price feeds, a compute service running inference, or a data pipeline producing analytics.

Why This Distinction Matters

"Who cares? Agents are the exciting part."

I get the instinct, but the distinction matters for two reasons.

First: It Changes What You Build

If you think ERC-8004 is an agent registry, you build agent directories and agent marketplaces.

If you understand it's a machine-economy trust layer, you build:

• Reputation aggregators for MCP tool servers
• Validation frameworks for oracles
• Discovery systems for DeFi services
• Infrastructure that agents consume, not just infrastructure that agents are

The value accrues to the ecosystem of things that are useful to agents, not just to agents themselves.

Second: It Changes the Adoption Curve

The agent-only framing makes ERC-8004 dependent on the maturity of autonomous AI agents—a market that's still early despite the hype.

But if you see ERC-8004 as general-purpose trust infrastructure, adoption doesn't have to wait for agents to be fully autonomous. MCP tool servers exist today. Oracles exist today. APIs exist today.

Any service that would benefit from decentralized discovery and reputation can start using these registries now.

What's Actually Being Built (and What Should Be)

The v2 spec is already live, and it proves the point—it ships with deeper MCP support, which makes sense precisely because MCP tools aren't agents. The spec's authors clearly see this.

From the Ethereum Magicians discussion, the standard is described as enabling "participants to discover, choose, and interact with agents across organizational boundaries"—note the word participants, not just agents.

Here's What I'd Want to See the Ecosystem Lean Into:

MCP tool reputation systems: Rate and review tool servers the way we rate NPM packages, but on-chain and composable.

Oracle quality registries: An oracle registers on ERC-8004, publishes its data endpoints, and accumulates verifiable reputation for accuracy and uptime.

DeFi service discovery: Automated services—liquidation bots, MEV searchers, keeper networks—all registering and building reputation, making them discoverable and evaluable by agents or other services.

Cross-protocol trust layers: An MCP server rated highly on ERC-8004's reputation registry becomes trustworthy to any agent on any chain, not just within one platform's walled garden.

Reputation-aware routing: Middleware that ingests ERC-8004 reputation data and dynamically routes requests to the best-performing service for a given task at a given moment. Agents no longer need to natively implement every capability—they become orchestrators that route each job to the highest-reputation provider.

Read the Spec, Not the Title

ERC-8004 is named "Trustless Agents" but it's really "Trustless Services" with agents as the most visible use case.

The architecture is deliberately generic. The registries are deliberately flexible. The protocol explicitly supports non-agent endpoints.

The next wave of value in the machine economy won't come from agents alone—it'll come from the ecosystem of services, tools, data providers, and infrastructure that agents rely on.

ERC-8004 is the trust layer for it all.