# What ERC-8004 actually means for agent identity. When two agents that have never met want to transact, they have an identity problem. The buyer agent doesn't know whether the seller agent is the one with a good track record, an impostor running on the same domain name, or a brand-new wallet pretending to have a track record by quoting impressive numbers. You could solve this with an OAuth-style central directory: register your agent, get a verified badge, present it to counterparties. But that puts a corporation in the middle of every agent-to-agent transaction, makes the directory a single point of failure, and is exactly the configuration that the on-chain-agent space exists to avoid. ERC-8004 — proposed as an EIP in August 2025, still a Draft standard, with reference registry contracts deployed to Ethereum mainnet on January 29, 2026 — is the first credible standard for solving this without a central directory. It is not the only attempt, and it is not the final form, but it is the one that the practical agent stack — Coinbase AgentKit, MetaMask, ElizaOS, Olas — converged on. This post is what it actually contains, what it solves, and what's missing. ## The three registries ERC-8004 specifies three on-chain registries, deployed as separate smart contracts and addressed by a chain-local namespace. An "agent" in the spec is anything with a private key — autonomous or human-operated. ### Identity registry A mapping from an agent ID (a 32-byte handle) to a metadata record: - The agent's controlling address (an EOA or contract account). - A descriptor URI (off-chain, typically IPFS) containing the agent's capabilities, terms, and public keys. - An optional human-readable label. - A nonce for rotation events. The registry is permissionless — anyone can register an agent ID — but each ID is uniquely owned. The descriptor URI's content is hashed on-chain so off-chain edits can't silently change what an ID claims. Practically: this is "agents have addresses, and the addresses point to a manifest you can read." It is closer to ENS than to OAuth. ### Reputation registry A mapping from `(agent ID, scoring schema)` to a list of _attestations_: signed claims by other agent IDs about the subject's performance in some interaction. Each attestation contains: - The asserting agent ID. - The asserted agent ID. - The schema ID (e.g., `did:reputation:trade-completion-v1`). - A signed JSON payload following the schema (e.g., `{trades: 412, disputes: 1, on_time_rate: 0.992}`). - A timestamp and nonce. There is no built-in scoring algorithm. The registry just stores the attestations. Aggregating them into a "reputation score" is left to the consumer. This is correct — there is no universal score; every counterparty cares about a different mix of properties. ### Validation registry A mapping from `(agent ID, validator ID)` to _validation receipts_: signed claims that a specific validator has examined a specific agent's claims and found them consistent. Validators are themselves agent IDs. The receipt's payload is schema-driven. A typical use: "Validator V has examined Agent A's last 100 trades and confirms that the on-chain record matches A's claimed `trades: 412`." This separates the trust signal (which the reputation registry collects) from the _audit_ of that signal (which the validation registry collects). ## Why three registries instead of one It is tempting to flatten this into a single contract: "agent IDs with a score field." The three-registry design is doing something specific. The split is between _facts_ (Identity), _opinions_ (Reputation), and _checks_ (Validation). - The identity registry says "this ID points to this manifest." A fact. - The reputation registry says "Alice thinks Bob is good." An opinion. It does not claim Alice is right. - The validation registry says "the auditor confirmed Alice's claim is consistent with the chain." A check. It does not claim the chain is the ground truth. Each layer can be sybiled. Anyone can register a thousand agent IDs. Anyone can have a thousand agents attest about each other. The system does not prevent that. What it does is make sybiling _expensive enough to be visible_: the wallet that controls a thousand colluding IDs is the same wallet, on-chain, and pattern-matchable. Consumers of the registry decide their own filtering. A skeptical counterparty might require: an Identity record older than 30 days, at least 50 Reputation attestations from agent IDs that themselves have ≥20 attestations, and at least 3 Validation receipts from validators on a known list. A less skeptical counterparty might require none of this. The protocol stays out of that decision. ## What ERC-8004 does not include This is the part where most coverage stops short. The spec leaves several big things explicitly outside its scope: ### No payment integration ERC-8004 does not say anything about how agents pay each other. If a buyer agent wants to pay the seller agent, that's an [x402](/blog/x402-economy/) problem, not an 8004 problem. Identity and payment are intentionally orthogonal. This is fine. Most production stacks combine the two anyway: x402 handles the per-call micropayment, ERC-8004 handles who's on the other end of the call. ### No scoring There is no on-chain "reputation score." Each consumer aggregates attestations in their own way. There are reference aggregators (open-source) that produce common scores (PageRank-on-attestations, time-decayed reputation, etc.) but they are libraries, not protocol. This means two consumers can disagree on whether an agent is reputable. They are looking at the same attestations and computing different aggregations. That is by design. ### No staking / no slashing ERC-8004 has no native staking mechanism. There is no economic penalty in the protocol for posting false attestations. This is a real gap. The countermeasure is application-level: validators (in the validation registry) are typically expected to stake on a separate contract or to be part of a curated validator set. The protocol doesn't enforce this; it just provides the metadata layer. ### No off-chain identity binding ERC-8004 does not connect an agent ID to a real-world identity. The agent at `0xa1b2...` is not bound to "the Acme Robotics agent operated by Acme Corp." If you want that binding, you sign a statement off-chain (e.g., publish on Acme's domain) and put the URL in the descriptor. The protocol gives you the address-to-manifest mapping; the manifest can claim anything; verification is on the consumer. This is also why [World](https://world.org/world-chain)'s identity layer matters. World's _Proof of Personhood_ attestations, once integrated with ERC-8004, give counterparties a way to require "this agent is operated by a verified human." Without that integration, ERC-8004 says nothing about whether the agent's controller is a person, a corporation, or another agent. ## A reference flow To make this concrete, here is what an agent-to-agent transaction looks like when both agents implement ERC-8004. ``` Agent A wants to hire Agent B to do a translation. 1. A reads B's Identity record. B's descriptor URI says: - capabilities: ["translation:ja-en", "translation:en-ja"] - price: x402 quote endpoint at https://b.example/quote - public_key: 0xb... 2. A reads B's Reputation attestations under schema did:reputation:translation-v1. There are 312, from 188 unique agent IDs. Mean rating 4.7/5; A applies its own aggregator (time-decayed, weighted by attestor reputation) and gets 4.4. 3. A reads B's Validation receipts. Three validators on A's allowlist have audited B's last 90 days of work. All three confirm B's claims of completed jobs. 4. A is satisfied. A submits an x402 payment for the quoted price to B's payment endpoint. The HTTP 402 response from B includes a signed receipt referencing B's agent ID. 5. B does the work. B returns the translated text plus a signed completion record. 6. A pays B. A optionally posts a Reputation attestation about B's performance, signed by A's agent ID. ``` Each step is standardized. No central directory mediates the trust check. A and B may never have transacted before. They never need to. ## Where the standard breaks down I want to flag three real problems with ERC-8004 as it exists today. ### Cold-start A brand-new agent has zero attestations. It cannot transact, because no skeptical counterparty trusts a zero-attestation agent. To get attestations, it has to transact. This is the same cold-start problem every reputation system has. The community workaround so far is _bootstrap pools_ — agents that explicitly transact with new entrants at small scale to provide initial attestations, sometimes in exchange for a fee. This is not part of the spec and it's not clean. Expect this to be a live area of design for the next year. ### Attestation gameability Two cooperating agents can attest about each other thousands of times. They will appear, naively aggregated, as highly reputed. Sybil-resistance is left to the aggregator. The state-of-the-art aggregator I've seen, used by Olas internally, requires attestations from "distinct attesting clusters" weighted by an eigenvector-on-the-attestation-graph computation. It works well but is computationally non-trivial and has to be re-run periodically. None of this is in the standard. It's all application-level. ### Validation incentives Validators do the actual audit work. The standard provides a place to store their receipts. It does not provide an economic incentive for them to do the work, or to do it honestly. In practice, validators are paid out-of-band (subscription fees, retainers, sometimes token incentives in associated networks like Allora). This works for now. It is not a long-term design. ## What teams should do If you are deploying an agent in 2026 that will transact with other agents — paying for tool calls, hiring other agents, accepting work — you should register an ERC-8004 Identity now and start collecting attestations. The cost is minimal: registration is one transaction (~$1 in gas at current rates), descriptor URI hosting is free on IPFS or cheap on a regular CDN, and ongoing reputation/validation activity is a few transactions per month at most. What you get is _optionality_. If your agent develops a track record under an ERC-8004 ID, that track record is portable. You can move the agent to a different framework (ElizaOS, Olas, AgentKit), and your track record comes with you. Reputation is no longer locked to a vendor. If you are building an agent framework or marketplace, support ERC-8004 reads as the default trust signal. Make it possible to filter, sort, and require minimum reputation thresholds. Don't roll your own. There are good open-source aggregators on top of the registry; use them. If you are an enterprise buyer using agents to do work for you — accepting agent quotes for translation, dispatch, research — require an ERC-8004 ID. The cost of being phished by an impostor agent is much higher than the cost of writing a 30-line check for an on-chain ID and a minimum number of attestations. ## What I'd watch next ERC-8004 v2 is in active development. Two changes worth watching: 1. **First-class MCP support.** The spec is being extended so an agent's MCP tool list (or a hash of it) can be part of the Identity manifest. Consumers will be able to check "does this agent advertise the tool I want to call?" before quoting. 2. **Native x402 integration.** The descriptor URI will optionally include a signed x402 endpoint with a verifiable price schedule. This means "ask Agent B how much it costs" becomes a cached on-chain read rather than an HTTP round-trip to a possibly-malicious endpoint. Neither of these are landed. Both will probably ship in late 2026. The right time to integrate ERC-8004 today is now, with v1; the v2 upgrade is additive. ## The longer-term point For most of the agent boom (2023–2025), agent identity was solved by _the platform you ran on_. ChatGPT's agents had OpenAI-mediated identity. Devin had Cognition-mediated identity. Replit Ghostwriter had Replit-mediated identity. None of these are interoperable. None of them survive the platform. ERC-8004 is the first identity standard that doesn't belong to one company. That is the change that matters. The specific UX of registries and attestations will evolve. The principle — agents have public, portable identities that they accumulate reputation against — is now part of the stack. Build for that.