ERC-8004 is an Ethereum Improvement Proposal that defines a trustless onchain registry for autonomous agents — a public, verifiable directory where AI agents can register their identity, operator, and capabilities so counterparties can check them before transacting. If agents are going to buy, sell, and negotiate on behalf of users, they need the same thing humans and businesses have had for centuries: a verifiable identity that other parties can look up. ERC-8004 is the Ethereum community's answer.

This article walks through what ERC-8004 specifies, why agentic commerce breaks without it, how the registry architecture works, and how the standard relates to ERC-4337 (account abstraction for agent wallets) and ERC-7683 (cross-chain intents). You will see why a smart-contract wallet alone is not sufficient, what "trustless identity" actually means onchain, and how a cross-chain settlement layer like Eco Routes extends ERC-8004 identity across every supported chain once an agent is identified.

The ERC-8004 specification defines a registry contract where any autonomous agent can publish a verifiable record of itself. At minimum, that record includes the agent's onchain address, the principal it represents (a user or organization), an optional operator attestation, and a set of capability claims. Other parties query the registry before interacting with the agent to confirm the record, verify the attestation, and decide whether to extend trust.

The design goal is trustless in the strict sense: no single entity issues or revokes identities. The registry is permissionless, any agent can register, and the claims on that registry are cryptographically verifiable. Counterparties do not have to take the registry operator's word for anything — they verify signatures and attestations themselves. This is the same trust model that makes ENS names and onchain token registries work, applied to a new class of entity.

Agentic commerce — the emerging category where autonomous agents transact with APIs, merchants, and each other, often through B2B stablecoin payout APIs — collapses without verifiable identity. A merchant deciding whether to accept a payment from an agent needs to answer: which user does this agent represent? What is its track record? What capability has it been authorized to exercise? Without an answer, the merchant is transacting with an opaque black box.

The problem is acute because agents scale in a way that humans and businesses do not. A single operator can spin up thousands of agents in minutes, and merchants have no practical way to onboard each one individually the way they onboard enterprise customers today. KYC, credit checks, and merchant-of-record contracts are not designed for software that instantiates itself on demand. What scales is a registry model — agents register, counterparties verify, trust is established by the cryptography rather than by bilateral onboarding.

The broader ecosystem signals this demand loudly. Anthropic's published work on tool use and computer use assumes an agent that can invoke external services but leaves identity to the developer. Stripe's Agentic Commerce Protocol specifies an identity envelope at the merchant layer. Coinbase's AgentKit and Google's Agent-to-Agent protocol both define their own identity primitives. ERC-8004 is the open, onchain complement to all of them.

A natural response is "agents already have wallets — isn't the wallet address their identity?" The address is necessary but not sufficient. An address tells you who signed a transaction; it tells you nothing about who the signer represents, what they are authorized to do, or whether they are accountable to any real-world entity.

Contrast with ENS, which binds a human-readable name to an address. Or with token contracts, which bind a ticker and metadata. ERC-8004 does the equivalent for agents: it binds an agent's operational address to the principal it represents, the capabilities it claims, and the attestations any third parties have made about it. With this binding, "pay this agent" becomes verifiable.

It also makes revocation tractable. If a user's agent is compromised, the user can update the registry entry to mark the agent deprecated; counterparties checking the registry before settlement decline the transaction. Without a registry, revocation is whack-a-mole per counterparty.

At the contract level, an ERC-8004 registry exposes a small, opinionated interface. Agents call a register function that emits an event with their address, principal, and a content-addressed hash pointing to a full metadata document stored off-chain (typically on IPFS or a similar addressable storage layer).

The metadata document contains the richer fields: capability claims ("this agent can execute ERC-20 transfers up to N per day"), operator attestations ("verified by Company X on date Y"), model provenance ("backed by a specific LLM version"), and links to audit logs if the operator chooses to publish them. Because the document is content-addressed, any mutation of the metadata produces a new hash, so a counterparty checking the registry always has an integrity-verifiable snapshot.

A second function lets the principal revoke or update an agent's entry. Revocation is reflected in the event log, so any indexer or counterparty caching registry state can detect it and refuse further interaction. This is the mechanism that makes "deactivate my agent" a single onchain action rather than a manual outreach to every merchant the agent has transacted with. For treasury teams running fleets of agents, this composes cleanly with stablecoin deposit automation systems that rely on deterministic counterparty identity.

Third-party attestations are the subtle piece. Any address can emit an attestation event pointing at an agent's registry entry. Attestations might come from a compliance provider ("KYC-verified principal"), an audit firm ("capability claims verified"), or an insurance underwriter ("coverage up to $X"). Counterparties decide which attestors they trust, and the verification is local — no central arbiter of truth.

ERC-8004 and ERC-4337 solve adjacent problems and compose naturally. ERC-4337 defines account abstraction — how a smart-contract wallet works, how it validates user operations, and critically how it can delegate narrow, time-bound authority via session keys. ERC-8004 defines the identity the wallet is used to prove.

A typical agent setup uses both. The user holds an ERC-4337 smart-contract wallet. They grant the agent a session key scoped to narrow spend limits and allow-listed counterparties. They register the agent in ERC-8004, binding the session key address to their principal. Counterparties querying the registry see that the agent is authorized by the principal, check the session key's on-wallet constraints, and transact.

Without ERC-4337, authorization has to be managed off-chain, which breaks the trustless property. Without ERC-8004, the session key is just a random address with no discoverable provenance. Together, they form the bounded, verifiable delegation that agentic commerce needs. EIP-7702 extends the ERC-4337 delegation pattern to regular externally-owned accounts, which will accelerate adoption once wallets widely support it.

If ERC-8004 answers "who is this agent," ERC-7683 answers "how does it express a cross-chain payment intent." ERC-7683 standardizes the format for cross-chain intents — a user or agent signs "pay X on chain A, deliver Y on chain B" and any compatible solver network can fulfill it. The two standards layer cleanly: an ERC-8004-identified agent signs an ERC-7683 intent, settlement lands on the destination chain, the receipt is bound to the agent's verifiable identity.

This matters because agent counterparties fan out across chains. An agent that only pays USDC to merchants on Base is a single-chain problem. An agent that pays one vendor on Arbitrum, another on Optimism, and a third on Solana is a cross-chain orchestration problem. ERC-7683 provides the portable intent format; the orchestration layer (Eco Routes, Across, Relay, LiFi) consumes it and selects the underlying rail. The agent's identity, proven via ERC-8004, travels with the intent. If you want the full landscape of cross-chain intent protocols, that article covers the field in detail.

ERC-8004 slots into a broader three-tier model of the agentic commerce stack. Rails are the underlying movement primitives — Circle's CCTP, LayerZero, Hyperlane, Wormhole. Layers orchestrate those rails and provide intent-based interfaces — Eco Routes, Across, Relay. Apps are what the agent touches. ERC-8004 identities travel through all three tiers: an agent proves who it is once, and that identity is preserved as its intents flow through the orchestration layer and settle on the underlying rail.

The reason this matters for ERC-8004 specifically is that the standard has to survive cross-chain transit. The registry is deployed on the chain it was proposed for, but counterparties on other chains need to verify identities. This is solved the same way every other cross-chain data problem is solved — with attestation bridging via a messaging protocol, or via the orchestration layer maintaining a synchronized view of the registry. For developers, the practical experience is that the agent's identity works everywhere the orchestration layer supports, which is also where cross-chain messaging protocols become load-bearing.

Eco Routes is the cross-chain settlement rail that ERC-8004-identified agents route through once they have proven who they are. An agent's registry entry tells counterparties who it represents and what it may do; Eco Routes tells the agent how to move stablecoins across any of 15 supported chains atomically. The two compose cleanly.

A worked example: a treasury agent registered under a corporate principal in ERC-8004, granted an ERC-4337 session key with a weekly spend cap, needs to pay invoices to vendors on four different chains. The agent signs ERC-7683 intents against Routes CLI or the Routes API; solvers compete to fulfill them; settlement lands atomically on each destination chain. The agent's ERC-8004 identity binds every transaction to its principal, which means the corporate finance team has a fully auditable trail. This is the kind of multi-chain vendor payment automation that was effectively impossible before these three standards matured.

Fifteen chains are supported today: Ethereum, Optimism, Base, Arbitrum, HyperEVM, Plasma, Polygon, Ronin, Unichain, Ink, Celo, Solana, Sonic, BSC, and Worldchain. Seven stablecoins route across them: USDC, USDT, USDC.e, oUSDT, USDT0, USDbC, and USDG. Developers integrating ERC-8004 agents into production workflows typically start with the API-first treasury primer to get the settlement layer wired up.

ERC-8004 is early, and it is moving fast. The spec is draft-stage at the EIP level, but reference registry contracts are already deployed on testnets and early mainnet deployments are emerging. Adoption depends on three things converging: wallet support for session-key delegation becoming table-stakes (underway with ERC-4337 and EIP-7702), agent frameworks integrating registry lookups by default (early signals from Coinbase AgentKit and others), and merchants accepting ERC-8004 identities as a verification channel for agent-originated payments.

The standard's keyword search volume — 700 searches per month globally with a page-level difficulty of 22 — suggests developer interest is outpacing published content, which is itself a signal that teams are actively building. For anyone designing an agent payment system in 2026, ERC-8004 should be a line item on the roadmap even if full adoption is a year out. The cost of retrofitting identity later is higher than the cost of designing for it now, especially if your agents are going to transact across the kinds of programmable stablecoin protocols that assume verifiable principals.

ERC-8004 is a draft Ethereum Improvement Proposal that defines a trustless onchain registry for autonomous agents. Agents register their identity, operator attestation, and capability claims in the registry; counterparties query it before transacting. The standard gives AI agents the verifiable identity they need to participate in agentic commerce without relying on a central issuer.

ERC-4337 defines account abstraction — how a smart-contract wallet validates operations and delegates narrow authority to session keys. ERC-8004 defines identity — who an agent represents, what it claims to do, who has attested to it. The two compose: an ERC-4337 wallet delegates to an agent, and the agent registers that delegation under ERC-8004.

Agents scale in ways humans and businesses do not — a single operator can spin up thousands. Traditional KYC and merchant-of-record contracts assume bilateral onboarding. A registry model lets any agent register, any counterparty verify, and trust be established cryptographically. Without this, merchants cannot safely accept agent-originated payments at scale.

As of early 2026, ERC-8004 is at the draft EIP stage. Reference implementations exist on testnets and early mainnet deployments are beginning, but widespread production use depends on wallet and agent-framework integration still rolling out. Teams building new agent systems in 2026 should design for the standard even if their initial deployment uses a simpler identity scheme.

The registry itself lives on a single chain, but agent identities can be referenced cross-chain via attestation bridging or by orchestration layers that maintain a synchronized view. In practice, agents using an orchestration layer like Eco Routes can transact across all 15 supported chains with a single ERC-8004 identity, because the settlement layer preserves the identity as intents are routed.