What is ERC-8004? How trustless agents work on Ethereum

ERC-8004, titled Trustless Agents, is an Ethereum standard that gives AI agents an onchain identity, a public reputation record, and a way to get their work verified, so they can transact across organizations without pre-existing trust. This guide covers how its three registries work, what is actually deployed on mainnet today, how the standard fits with A2A, MCP, and x402, and what to watch for before you build on it.

What is ERC-8004?

ERC-8004 was proposed in August 2025 by authors from MetaMask, the Ethereum Foundation, Google, and Coinbase, and it defines three registries. The Identity Registry records who an agent is. The Reputation Registry records what its clients say about it. The Validation Registry records whether independent validators checked its work.

The spec is explicit that trust is not one-size-fits-all. In its own words, trust models are "pluggable and tiered, with security proportional to value at risk, from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis." An agent booking a dinner reservation can lean on reputation scores. An agent managing a treasury needs its work re-verified by someone with money at stake.

Why do AI agents need a trust layer?

Every trust system you use today assumes a platform in the middle. Marketplace reviews live in one company's database. Chargebacks exist because a card network sits between buyer and seller. OAuth logins work because a large identity provider vouches for you. That model breaks for autonomous agents, which are built to work across companies, clouds, and jurisdictions with no shared operator.

The rest of the agent stack has filled in around this gap. The Model Context Protocol (MCP) connects an agent to tools and data sources. Agent2Agent (A2A) lets agents find each other and exchange structured messages. x402 lets them pay for services over plain HTTP. Each of these assumes you have already decided which counterparty to work with. None of them helps you make that decision.

That is the job ERC-8004 takes on, and it is why the registries live on a blockchain rather than in anyone's database. A DeFi agent choosing an execution venue, a research agent hiring a data-labeling agent, and a merchant deciding whether to serve an unknown buyer all need the same three lookups. Who is this agent? What happened when others worked with it? Did anyone verify its output? ERC-8004 puts those answers somewhere no single party controls, in one schema every agent can read.

How does the ERC-8004 identity registry work?

Each registered agent is an ERC-721 token, the same standard behind NFTs. Registering calls register() on the Identity Registry and mints a token whose ID becomes the agent's number. The agent's full identifier combines the chain and registry address with that ID, so "agent 4,205 on Base" is unambiguous globally.

The token's URI points to a registration file, hosted on IPFS, HTTPS, or embedded directly onchain, that describes what the agent is and how to reach it. A trimmed-down registration file looks like this:

The services array is the discovery payload. It advertises the agent's live endpoints across whatever protocols it speaks, including A2A, MCP, ENS names, and decentralized identifiers. The supportedTrust field declares which trust models the agent opts into. The spec notes that if it is absent, the registration is used for discovery only.

Building on ERC-721 buys a lot for free. Ownership, transfer, and delegation already work, wallets and marketplaces already render the tokens, and the ecosystem's tooling applies unchanged. The registry also separates the identity from the keys that act day to day. setAgentWallet binds a working wallet to the agent with a signed authorization, so the owner of the identity token and the wallet signing transactions can be different keys with different blast radii. That is the same separation we recommend when giving an agent a wallet in the first place, where the agent gets scoped, time-bound signing access instead of a raw private key.

How does the ERC-8004 reputation registry work?

Any address can rate any agent by calling giveFeedback on the Reputation Registry. A feedback entry carries a signed numeric value with configurable decimals, so scores can be negative and precise rather than a coarse one-to-five, plus up to two tags for filtering and an optional URI pointing to a richer offchain writeup, committed onchain by its hash. The only hard restriction is that an agent's owner and operators cannot rate their own agent.

Two design choices matter more than the function signatures. First, clients never register anywhere, which keeps the barrier to leaving feedback at zero and lets services sponsor the gas for their users' reviews. Second, the registry deliberately computes no canonical score. It stores raw signals, offers summary and read functions, and leaves interpretation to whoever queries it. Discussion on the proposal argued early that a single aggregate reputation number invites monopoly dynamics and gaming, so scoring lives in the indexer layer, where different consumers can weigh the same data differently.

The offchain feedback file is where reviews get teeth. It can reference the exact MCP tools or A2A tasks the interaction used, and it can embed proof of an x402 payment, tying the review to a transaction that verifiably happened. A review backed by a payment receipt is a much stronger signal than a bare score from an anonymous wallet, and filtering for exactly that kind of review is how serious consumers of the registry are expected to use it.

How does the ERC-8004 validation registry work?

Feedback scores tell you what past clients thought. For higher-value work, that is not enough, and the output itself needs checking. The Validation Registry lets an agent request that a named validator check a specific piece of work: validationRequest records the validator, the agent, and a hash-committed pointer to the work, and the validator answers with validationResponse, scoring the result from 0 to 100 with its own hash-committed evidence.

What "checking" means depends on the validator. It can re-execute the task and compare outputs, with stake it loses if it attests dishonestly. It can attest that the agent ran inside a trusted execution environment (a TEE, hardware that can prove what code it executed). It can verify a zero-knowledge machine learning proof (zkML, a cryptographic proof that a specific model produced a specific output). The registry does not care which; it standardizes the request-and-response plumbing.

One current-state caveat that almost no coverage mentions. The official multi-chain deployment ships the Identity and Reputation registries, but the Validation Registry was pulled back for rework with the TEE community and is not part of the official mainnet set today. Teams that need validation now wire it through specific providers, such as EigenCloud's trustless agents integration, which pairs ERC-8004 identity with its own verifiable compute. Check the official contracts repo for where deployment stands before you build against it.

Which trust model should an agent use?

The spec's value-at-risk framing turns into a fairly clean decision rule. Match the cost of verification to the cost of being wrong.

The models also stack. A production agent might run in a TEE, carry a reputation history, and submit high-value outputs for staked re-execution, presenting all three signals through the same supportedTrust declaration.

How do ERC-8004, A2A, MCP, and x402 fit together?

The agent stack is easiest to hold as four layers with four different owners. MCP, from Anthropic, connects an agent to tools and context. A2A, started by Google, handles agent-to-agent discovery and messaging. x402, driven by Coinbase, moves the money, one of several competing agent payment protocols. ERC-8004 anchors trust, and it is deliberately the only layer that lives on a blockchain, because identity and reputation are only useful if no counterparty controls them.

A single interaction can touch all four. A buyer agent queries the Identity Registry for agents advertising the skill it needs, fetches a candidate's registration file, and checks its reputation summary and validations. It opens an A2A session to negotiate the task, or calls the seller's MCP endpoint directly. It pays the x402 invoice the seller returns. When the work is done, it calls giveFeedback with a reference to the payment, and the seller's next prospective client sees a review with a receipt attached.

Nothing in the stack requires the whole loop. Teams adopt x402 without ERC-8004, and register identities without ever requesting validation. But the layers were designed to reference each other. The registration file lists A2A and MCP endpoints, and feedback files embed x402 receipts, so composing them takes configuration rather than glue code.

How do you build on ERC-8004?

Reading the registries requires no special tooling, because they are ordinary contracts. Identity lookups are ERC-721 calls, and every registry emits events you can index. We serve all of the major deployment chains, so a standard RPC endpoint is enough to start. Fetching an agent's registration file takes one read:

From there, the pieces map to infrastructure you likely already run. Webhooks turn new registrations and feedback events into pushes instead of polling, and how you arrange the loop around those events is covered in our guide to onchain AI agent architectures. The agent's operational wallet should be a scoped signer rather than a raw key, the pattern our onchain agents guide walks through end to end. And the agent can run its own infrastructure relationship autonomously, since agents can sign up for our platform with a wallet as identity and pay per call over x402, no human in the loop. If you build from a coding agent, the Alchemy plugin for Claude Code bundles our MCP server and skills into one install.

Everything an ERC-8004 agent does downstream of the registry, reading chain state, watching events, signing transactions, and paying for its own API usage, runs on infrastructure we built for agents as first-class users. Grab a free endpoint through the Alchemy CLI, or let your agent onboard itself. No API key handoff, no contract, and nothing in the signup loop that needs a human.

What are the limitations of ERC-8004?

The standard is young, and its sharp edges are documented in its own discussion thread. The ones that should shape your design:

• Sybil feedback is cheap. Wallets cost nothing, so raw reputation scores are manufactured easily. Consume feedback filtered by known clients or payment proofs, never unfiltered averages.
• Identity is transferable. An agent identity is a standard ERC-721, so an aged identity with a clean history can be sold, and its reputation goes with it. Track ownership changes before trusting history.
• Scores age badly. Agents are stochastic, and a model update can change behavior overnight, so last month's feedback describes last month's agent.
• Reputation stays on one chain. An agent registered on Base starts from zero on Arbitrum. Cross-chain aggregation is an indexer problem the standard does not yet solve.
• The interfaces may still move. The standard remains a draft and has already been redesigned once. Pin your integration to the deployed contracts, and watch the spec before depending on newer surfaces.

None of these breaks the standard's actual claim, which was never that onchain reputation is unfakeable. The claim is that agent trust signals belong in a public, shared, permissionless schema instead of scattered across private databases. Judged on that claim, it is live and already being read by real systems.

Frequently asked questions

What is ERC-8004 and how does it enable trustless AI agents?

ERC-8004 is an Ethereum standard that registers AI agents onchain through three registries covering identity, reputation, and validation. Agents get a portable, verifiable identity as an ERC-721 token, clients post feedback publicly, and validators attest to work quality, so agents can transact across organizations without pre-existing trust.

Is ERC-8004 live on mainnet?

Yes. The Identity and Reputation registries have run on Ethereum mainnet since January 2026 and are deployed at the same addresses on more than twenty networks.

Does ERC-8004 have a token?

No. ERC-8004 is a smart contract standard, not a project with a token. Registering an agent mints an ERC-721 identity token specific to that agent, but there is no fungible ERC-8004 asset, and anything marketed as one is unaffiliated with the standard.

Can an ERC-8004 agent identity be sold?

Yes. Agent identities are standard ERC-721 tokens, so they transfer like any NFT, and accumulated reputation travels with the token. That makes ownership history part of due diligence, since a clean reputation may have been purchased rather than earned by the current operator.

Which chains support ERC-8004?

The official registries are deployed at identical addresses on more than twenty EVM networks, including Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, and Monad. Alchemy provides RPC and data APIs across these chains, so agents can read and write the registries anywhere they are deployed.

How is ERC-8004 different from x402 and A2A?

They solve different layers of the same stack. A2A handles how agents find and message each other, x402 handles how they pay each other over HTTP, and ERC-8004 handles whether they should trust each other, by anchoring identity, reputation, and validation records onchain. Production agent systems typically compose all three.