What Is ERC-8004? Ethereum's Standard for Trustless AI Agent Identity and Reputation

A2A agent cards and MCP server cards solve discovery: they tell a client what an agent can do and how to call it. Neither solves a harder problem — deciding whether to trust an agent you've never dealt with before, run by an operator you have no relationship with. ERC-8004, an Ethereum standard formally titled "Trustless Agents," is built specifically for that gap: a portable, on-chain identity for agents, plus registries where reputation and independent validation results live outside any single platform's control.

This post explains what ERC-8004 actually defines, how its three registries fit together, how it differs from the off-chain agent cards you may already be publishing, and where it stands today.

The Problem It's Solving

Off-chain agent identity — an A2A agent card, an MCP server card — is self-asserted and lives wherever the agent's operator chooses to host it. That's fine for discovery, but it means nothing stops an operator from serving different cards to different callers, deleting a card the moment it's inconvenient, or standing up a new domain with a fresh identity and no history the moment their old one earns a bad reputation.

ERC-8004 addresses this by moving three things on-chain, where they're portable, persistent, and outside the agent operator's unilateral control: the identity itself, the reputation signals other parties have published about it, and the results of independent validation checks.

The Three Registries

ERC-8004 defines a small set of smart contracts, not a single monolithic one:

Registry	What it stores	Analogous to
Identity Registry	An ERC-721 token per agent — a portable, transferable, ownable identity	A domain name, but for an agent instead of a website
Reputation Registry	A standardized interface for publishing and reading feedback signals about an agent's behavior	Review and rating systems, but composable across platforms
Validation Registry	Hooks for third-party validator contracts to publish independent attestations of an agent's outputs or behavior	An audit report, published where anyone can check it

None of the three requires the others to function, but they're designed to compose: an agent registers an identity, other agents or users attach reputation feedback to that identity over time, and validators can independently attest to specific claims — "this agent's last 100 completions matched its stated capability" — without needing to trust the agent's own word for it.

Identity Registry: Why ERC-721

Using the ERC-721 non-fungible token standard for agent identity isn't incidental — it's what makes the identity portable in a way a database row in a centralized registry never could be. An ERC-721 token is natively transferable (an agent's identity can change hands, e.g. in a business acquisition, without losing its history), natively ownable and verifiable by any wallet or contract that already speaks the ERC-721 interface, and immediately compatible with every NFT-aware tool, wallet, and explorer that already exists — no bespoke tooling required to look one up.

Concretely, registering gives an agent an on-chain token ID plus a URI (via the standard tokenURI/URIStorage pattern) pointing at metadata: name, capabilities, and — often — a link back to the agent's off-chain A2A or MCP identity documents. This is the seam where the on-chain and off-chain worlds meet: ERC-8004 doesn't replace your agent card, it anchors it.

Reputation and Validation: Two Different Kinds of Trust Signal

It's worth being precise about what each registry actually proves, because they answer different questions:

• Reputation answers "what have other parties said about this agent?" It's subjective, cumulative, and gameable in the way any review system is — useful as a signal, not as proof.
• Validation answers "did an independent party check a specific claim, and what did they find?" A validator contract publishes a result — pass, fail, a score — against something checkable, which is a fundamentally stronger claim than an unverified review.

A production system consuming ERC-8004 data should treat these as complementary, not interchangeable: reputation for general signal, validation for anything a decision actually depends on.

How This Differs from A2A Cards and MCP Server Cards

If you're already publishing an A2A agent card or MCP server card, you might reasonably ask why you'd need anything else. The honest answer is that they solve adjacent, not identical, problems:

	A2A / MCP cards	ERC-8004
Where it lives	Your own domain, self-hosted	On-chain, outside your control
What it proves	What you claim your agent can do	Who you are, persistently, plus what others independently say
Can it be silently changed?	Yes — you control the file	No — registry state is public and immutable once written
Requires a wallet?	No	Yes

The practical pattern emerging across the ecosystem is layered, not either-or: publish a normal agent card for discovery and capability advertisement, and anchor it to an ERC-8004 identity for portability and trust signals that survive a domain change or a platform dispute.

Where This Meets Payments

Identity and payment are separate concerns that increasingly get used together: before an autonomous agent pays a counterparty via a protocol like x402, checking that counterparty's ERC-8004 identity and reputation first is a natural pre-payment gate — a way to answer "should I trust this agent enough to send it money" before answering "how do I send the money." Neither standard depends on the other, but the combination is where a lot of current design work in agentic commerce is happening.

Current Status

ERC-8004 is still a draft EIP — worth treating as an early-stage, moving target rather than a finished standard. The reference implementation went live on Ethereum mainnet on January 29, 2026, with earlier testnet deployments still active on Base Sepolia, Linea Sepolia, and Hedera Testnet. Real adoption depends on three things converging that are still in progress: wallets supporting session-key delegation so agents can transact without a human signing every action (built on standards like ERC-4337 and EIP-7702), agent frameworks doing registry lookups automatically rather than as a manual integration step, and enough agents actually registering that reputation and validation data become dense enough to be useful.

None of that makes it something to ignore — a standard backed by this much simultaneous interest from wallet infrastructure, agent frameworks, and the Ethereum ecosystem tends not to stay a research curiosity for long. It does mean treating any specific contract address, ABI, or registered identity you see today as provisional rather than permanent.

What to Check Before You Rely on One

If you're consuming ERC-8004 data to make a trust decision, a few questions are worth asking before you act on it: Is the identity registered on the network you think it is, and is that network's deployment the canonical one rather than a fork or a testnet you mistook for mainnet? Does the reputation data come from a large enough, diverse enough set of parties to mean anything, or is it a handful of self-referential entries? Is there an actual validation result backing the specific claim you care about, or only unverified reputation? And does the on-chain identity's metadata actually link back to a real, reachable agent card or server card you can independently check?

Agent identity is moving on-chain the same way domain names, TLS certificates, and package registries did before it — each time trading a fully centralized authority for a system anyone can verify but no single party fully controls. ERC-8004 is early, but it's the clearest current answer to a question the agentic web can't avoid for long: when an agent says it's someone, how would you actually know?