ERC-8004 Goes Mainnet: Ethereum's Trust Layer for AI Agents

When AI agents cross organizational boundaries, a question emerges: should I trust this agent?

Agent registries are clearly a sought-after solution. NANDA’s A Survey of AI Agent Registry Solutions covers the emerging landscape: MCP Registry, A2A Agent Cards, AGNTCY, Microsoft Entra Agent ID, and their own AgentFacts. SSI trust registries are another candidate.

The Ethereum ecosystem, together with Consensys, Google, and Coinbase, also came up with a solution. ERC-8004 adds on-chain registries for agent identity, reputation, and validation. And it’s going live on mainnet:

For implementation details, see the full specification.

Why This Matters

A2A solves agent discovery and communication, but assumes usage within trust boundaries. As co-author Marco De Rossi writes: “Web3/trustless use cases were ignored. Discovery and trust assumptions were overlooked.” The same goes for MCP servers.

When agents cross organizational boundaries, DNS and TLS aren’t enough. You can discover an agent. You can talk to it. But can you trust it? Can you verify its track record? Can you validate that its outputs are correct?

ERC-8004 adds three registries to solve this:

The Trust Flow

An example flow through the three registries. x402 is mentioned in the spec but orthogonal to the protocol. On desktop, the diagram shows best-effort example requests and responses (not every implementation detail was cross-checked).

Domain Verification

Since endpoints can point to domains not controlled by the agent owner, ERC-8004 includes optional domain verification. Agents can prove control by publishing /.well-known/agent-registration.json on the endpoint domain.

Users can treat the endpoint as verified if the file is reachable over HTTPS and includes a registrations entry matching the on-chain agentRegistry and agentId.

The supportedTrust field is optional. If absent, ERC-8004 is used only for discovery, not for trust.

Open Standards, Industry Leaders

The authors are industry leaders shaping agentic AI infrastructure:

This coalition represents convergence on interoperable agent infrastructure.

One Standard, Many Chains

ERC is a standard, not a chain lock-in. Deploy on L2s (Base, Arbitrum) for low gas, permissioned Besu for enterprise, or mainnet for censorship resistance. That said, scattered registries across chains would defeat the purpose of a unified trust layer. The mainnet deployment matters because it establishes a canonical registry.

An agent registered on chain A can still operate and transact on other chains. The identity is portable.

Limitations

The spec is honest about what ERC-8004 can’t solve:

• Sybil attacks are possible: fake agents inflating reputation. The protocol makes signals public and filterable by reviewer. Reputation systems built on top can add trust scoring for reviewers.
• Capability verification: the ERC cryptographically links the registration file to the on-chain agent, but can’t guarantee advertised capabilities are functional or non-malicious. That’s what the three trust models (reputation, validation, TEE attestation) are designed to address.
• Audit trail integrity: on-chain pointers and hashes cannot be deleted, ensuring permanent records.

What’s Next

ERC-8004 won’t solve agent trust alone. It’s one of several emerging approaches to portable agent identity and reputation, with the distinct angle of on-chain settlement and composability with existing Web3 primitives.

For those building multi-agent systems, this is infrastructure worth watching. For all the details, see the full specification.