ERC-8004: The standard that gives AI agents on-chain identity, reputation, and trust

How four teams from MetaMask, Ethereum Foundation, Google, and Coinbase built the infrastructure layer for the autonomous agent economy

On January 29, 2026, a set of smart contracts went live on Ethereum mainnet that could quietly reshape how AI agents interact with the world. ERC-8004, authored by Marco De Rossi (MetaMask/ConsenSys), Davide Crapis (Ethereum Foundation), Jordan Ellis, and Erik Reppel (Coinbase), introduces three on-chain registries that give AI agents something they’ve never had: verifiable identity, portable reputation, and cryptographic validation.

After digging through 7 sources – the EIP specification, the official launch announcement, the Ethereum Magicians discussion, an Eco.com explainer, a QuillAudits security analysis, the awesome-erc8004 ecosystem list, and x402 protocol documentation – the picture is clear: ERC-8004 is technically sound, strategically positioned, and already generating real ecosystem activity. But it also faces real challenges around composability, Sybil resistance, and developer experience.

The trust problem no one had solved

AI agents are proliferating fast. Gartner projects 40% of enterprise applications will embed agents by 2026. But here’s the problem: existing agent protocols – Google’s A2A (Agent-to-Agent) and Anthropic’s MCP (Model Context Protocol) – handle communication and capability advertisement. Neither provides a way to verify an agent’s identity or track record across organizational boundaries.

Consider a concrete scenario: your AI coding agent needs to hire a testing agent from another company. How does it know the testing agent is legitimate? That it actually delivers quality results? That it won’t just take payment and disappear? Today, the answer is: it doesn’t. Every cross-boundary agent interaction requires a human to vet the counterparty, which defeats the purpose of autonomous agents.

ERC-8004 solves this by putting agent identity and reputation on Ethereum – not as a centralized database controlled by one company, but as permissionless infrastructure that any agent can use.

Davide Crapis: “Ethereum is in the unique position to be the platform that secures and settles AI-to-AI interactions.”

The three-registry architecture

ERC-8004’s design is deliberately minimal. Three singleton registries, each deployed once per chain, handle identity, reputation, and validation independently. This separation means different reputation algorithms, validation methods, and payment protocols can compete and evolve without coupling.

Registry 1: Identity (ERC-721 agent IDs)

Every agent gets a unique on-chain identity as an ERC-721 NFT. The global identifier format:

eip155:{chainId}:{identityRegistry}/{agentId}

Registration is simple:

function register(string calldata agentURI, MetadataEntry[] calldata metadata)
    external returns (uint256 agentId)

Each agent ID points to an off-chain “agent card” – a JSON metadata file describing the agent’s capabilities, endpoints, and supported protocols. The agent card supports URIs via IPFS, HTTPS, or on-chain data URIs.

Agents can also set a dedicated wallet address (separate from the NFT owner) for receiving payments:

function setAgentWallet(uint256 agentId, address newWallet, uint256 deadline,
                        bytes calldata signature) external

This requires an EIP-712 signature (for EOAs) or ERC-1271 proof (for smart contract wallets), and the wallet is automatically cleared on token transfer to prevent stale associations.

Registry 2: Reputation (structured feedback)

The Reputation Registry stores structured feedback on-chain with off-chain extensibility:

function giveFeedback(
    uint256 agentId,
    int128 value,
    uint8 valueDecimals,
    string calldata tag1,
    string calldata tag2,
    string calldata endpoint,
    string calldata feedbackURI,
    bytes32 feedbackHash
) external

The tag system captures different metrics:

Feedback is immutable – it can be revoked (marked as withdrawn) but never deleted. Agents can append responses, creating a two-sided record. The off-chain feedback document supports proofOfPayment fields with transaction hashes, linking reputation directly to economic activity.

One design detail worth noting: the submitter cannot be the agent’s owner or approved operator. This prevents self-reviews, though it doesn’t fully solve Sybil attacks (more on that below).

Registry 3: Validation (third-party verification)

The Validation Registry enables independent verification of agent work. A requester submits a validation request with a hash-committed payload; a validator responds with a score from 0 (failed) to 100 (passed):

function validationResponse(
    bytes32 requestHash,
    uint8 response,
    string calldata responseURI,
    string calldata responseHash,
    string calldata tag
) external

This registry isn’t on mainnet yet, but it’s the one I keep thinking about. A coding agent submits work, a validator re-executes the code and confirms it passes tests, and the validation score feeds into the agent’s reputation. That’s the missing piece for agents hiring other agents.

The agent card: a universal discovery layer

The agent card metadata format doesn’t get enough attention. It supports endpoints for A2A Protocol, MCP, OASF, ENS, DID, email, and arbitrary web services – all in one registration:

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "agentName",
  "description": "Natural language description of capabilities",
  "services": [
    { "name": "A2A", "endpoint": "https://agent.example/.well-known/agent-card.json" },
    { "name": "MCP", "endpoint": "https://mcp.agent.eth/", "version": "2025-06-18" },
    { "name": "ENS", "endpoint": "myagent.eth" }
  ],
  "x402Support": true,
  "supportedTrust": ["reputation", "crypto-economic", "tee-attestation"]
}

This makes ERC-8004 protocol-agnostic. An agent registered on-chain can be discovered via Ethereum but communicate via MCP, A2A, or plain HTTP. The on-chain layer handles trust; the off-chain layer handles capability. Optional domain verification via .well-known/agent-registration.json files lets agents prove they control their declared endpoints.

x402: the payment layer that closes the loop

ERC-8004 handles identity and trust. x402 handles payment. Together, they create a trust-and-pay loop:

1. Agent A discovers Agent B via the Identity Registry
2. Agent A checks Agent B’s reputation via the Reputation Registry
3. Agent A pays Agent B via x402 (HTTP 402 status code + USDC)
4. The payment proof feeds back into Agent B’s reputation

x402, developed by Coinbase and co-launched with the Cloudflare-backed x402 Foundation, uses the HTTP 402 (“Payment Required”) status code for pay-per-request APIs. Client requests a resource, server returns 402 with payment instructions, client pays (primarily USDC on Base, where costs are sub-cent), a facilitator verifies, and the server delivers.

Erik Reppel said “2026 will be the year of agentic payments.” So far: Stripe adopted x402 in February 2026 for USDC payments on Base, and on Solana, x402 has processed 35M+ transactions and $10M+ in volume.

The x402Support boolean in the agent card signals payment capability. The proofOfPayment field in reputation feedback documents creates cryptographic proof linking payments to outcomes.

The ecosystem: SDKs, scanners, and TEE infrastructure

The awesome-erc8004 repository shows substantial developer activity. During three months on testnet before mainnet launch, 10,000+ agents were registered with 20,000+ feedback entries.

SDKs in three languages:

• TypeScript: ChaosChain SDK (includes ERC-8004 + x402 + A2A), erc-8004-js
• Python: erc-8004-py, chaoschain-sdk
• Go: Praxis Go SDK

Infrastructure includes Automata Network and Phala Network for TEE attestation/deployment, and Sparsity for AI verification. Chitin provides “soul identity” for agents on Base L2 with an MCP server.

Community resources include three scanners for browsing registered agents, a dedicated course, two recorded “Trustless Agents” calls, and a Devconnect event from November 2025.

Testnet deployments on Ethereum Sepolia, Base Sepolia, Linea Sepolia, and Hedera Testnet. Mainnet deployments planned for Base, Optimism, Polygon, Linea, Arbitrum, Monad, Gnosis, Celo, and Scroll.

The team and institutional backing

The author list:

• Marco De Rossi – MetaMask (ConsenSys)
• Davide Crapis – Ethereum Foundation’s dAI team (which has incorporated ERC-8004 into their 2026 roadmap)
• Jordan Ellis – Community contributor
• Erik Reppel – Coinbase (also behind x402)

The contracts were audited by Cyfrin, Nethermind, and the Ethereum Foundation Security Team – three independent security reviews, which is unusual for a Draft ERC.

Security considerations

QuillAudits’ analysis identifies four primary attack vectors:

1. Domain squatting via mempool front-running: an attacker watches for agent registration transactions and front-runs them to claim domains. Mitigation: commit-reveal schemes.

2. Unauthorized feedback: uncontrolled giveFeedback() calls could spam agents with fake reviews. The spec prevents self-reviews but doesn’t fully address coordinated Sybil attacks.

3. Storage bloat: unbounded ValidationRequest entries could inflate on-chain storage costs. No hard cap is defined.

4. Sybil identity creation: creating many fake agent identities to game reputation. The spec acknowledges this and defers to application-layer implementations (bonds, trust scoring, ZK proofs).

ERC-8004’s security approach mirrors Ethereum more broadly: don’t prevent bad behavior – make it transparent and economically punishable. Feedback is immutable, all events are indexed via subgraphs, payment proofs create accountability, and TEE attestations provide cryptographic behavior verification.

The community debate: on-chain vs. off-chain composability

The Ethereum Magicians discussion (45 likes, active author participation) shows the biggest unresolved tension.

The current design stores feedback data on-chain but aggregates reputation scores off-chain. This optimizes for gas efficiency but means smart contracts cannot natively read an agent’s reputation score to gate transactions.

spengrah argued that off-chain-only reads limit composability: DeFi protocols can’t require minimum reputation to participate, escrow contracts can’t auto-release based on validation scores, and reputation-gated marketplaces need off-chain oracles.

Marco-MetaMask defended the approach through gas efficiency and the need for multiple competing aggregation algorithms rather than a single on-chain score.

daniel-ospina warned that single aggregate reputation scores “facilitate monopolistic behavior.”

pcarranzav pointed out that the .well-known/agent-registration.json domain verification approach works for honest actors but doesn’t prevent domain squatting.

The v2 roadmap addresses this with “flexible on-chain reputation storage for smart contract composability,” suggesting the team views this as a real problem worth solving.

Three trust models for different stakes

ERC-8004 defines three trust models calibrated to transaction value:

Reputation-based (low stakes): client feedback aggregated on-chain. Good for low-value, high-frequency interactions. Simple but vulnerable to Sybil attacks.

Cryptoeconomic validation (medium stakes): validators stake capital and face slashing for incorrect verifications. Staked re-execution or zkML proofs verify agent outputs.

TEE attestation (high stakes): hardware-backed proofs via Trusted Execution Environments. Automata Network and Phala Network are already building TEE infrastructure for ERC-8004 agents.

What’s next: the v2 roadmap

Based on the Eco.com explainer and community discussions, v2 is expected to include:

• Deeper MCP support for tighter agent-to-agent communication
• Flexible on-chain reputation storage, addressing the composability concerns
• Cleaner x402 integration with more standardized payment flows
• Refined schemas for specialized agent marketplaces (trading agents, coding agents, research agents)
• Cross-chain reputation bridges – currently per-chain singletons are deployed independently
• Validation Registry mainnet deployment

Getting started as a developer

For developers looking to integrate ERC-8004:

1. Register an agent on testnet. The simplest path is the TypeScript SDK:

// Using ChaosChain SDK (TypeScript)
import { IdentityRegistry } from '@chaoschain/erc-8004';

const registry = new IdentityRegistry({ chain: 'sepolia' });
const agentId = await registry.register({
  agentURI: 'https://your-agent.com/agent-card.json',
  metadata: [{ key: 'version', value: '1.0.0' }]
});

2. Create an agent card following the registration JSON schema, listing your agent’s endpoints (A2A, MCP, HTTP, etc.) and supported trust models.

3. Submit feedback after agent interactions to build reputation:

await reputationRegistry.giveFeedback({
  agentId: 42,
  value: 95,
  valueDecimals: 0,
  tag1: 'successRate',
  endpoint: 'https://agent.example.com/code-review'
});

4. Explore the ecosystem via the awesome-erc8004 repository for SDKs, scanners, and integrations.

Takeaways

ERC-8004 is real infrastructure. Mainnet deployment, three independent security audits, backing from MetaMask/EF/Google/Coinbase, and 10,000+ testnet registrations before launch.

The x402 integration is the economic piece that makes the rest work. Discover, evaluate, pay, feedback – that closed loop is what makes autonomous agent-to-agent commerce viable rather than theoretical.

The on-chain composability debate will shape v2. If on-chain reputation storage gets added so smart contracts can read it natively, DeFi integrations (reputation-gated protocols, automated escrow, insurance underwriting) become possible.

Sybil resistance is the open problem. The standard acknowledges but doesn’t solve coordinated fake identity attacks. High-value use cases need application-layer solutions until the standard itself addresses this.

The Validation Registry, once on mainnet, enables verified task completion – agents hiring other agents with proof of work quality before releasing payment.

For developers building agent platforms: ERC-8004 provides portable identity and reputation that travels beyond any single platform. Early integration means your agents carry their track record everywhere, which matters when the alternative is being locked into a proprietary reputation system.