ERC-8004: trustless agent identity, and what it unlocks for LLM4Agents Agent Gen

An autonomous agent without a portable identity is a process with amnesia. It cannot prove it did good work last week, it cannot be hired by a counterparty who has never seen it before, and it cannot carry its reputation to a different platform when the one it was born on shuts down. ERC-8004 — co-authored by MetaMask, the Ethereum Foundation, Google and Coinbase, and live on Ethereum mainnet since 29 January 2026 — solves that problem the way the rest of the internet solved DNS: with a minimal on-chain registry that any service can read and any agent can resolve. This post walks through what ERC-8004 actually is, the three registries it standardises, how it composes with x402 and Google's A2A protocol, and what we're building into Agent Gen on top of it.

The problem ERC-8004 solves

Agent platforms today are silos. An agent built on platform A has an identity that means nothing on platform B. The reputation it earned across 10,000 tasks on platform A becomes zero when its operator migrates. If platform A goes dark, the agent's history goes with it. And a counterparty looking to hire an agent for a job has no standard way to ask "is this agent who it claims to be, and does it have a track record."

This is the same problem the early web had with identity. It was eventually solved at the network layer with DNS, X.509 certificates, and OAuth. None of those primitives translate cleanly to autonomous agents because they assume a human signs up, an organisation registers, and a server keeps the keys. An agent that registers itself, signs its own transactions, and outlives the legal entity that created it needs different infrastructure.

ERC-8004's bet is that the chain is the right substrate for that infrastructure. Identity lives in a registry contract on Ethereum (and any EVM-compatible chain that deploys the singleton). Reputation accumulates in a second registry. Validation hooks let third parties cryptographically attest that the agent did what it claimed. None of these registries depend on the platform that hosts the agent; all of them survive the platform.

A short history

The proposal was first published as a draft in August 2025 by Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google) and Erik Reppel (Coinbase). The author list is the headline: an EIP that bridges Ethereum identity, Google's agent protocols and Coinbase's payment infrastructure starts life with the three constituencies that have to use it already in the room.

The standard was demonstrated at DevConnect Istanbul in November 2025 with the first end-to-end implementations — agents registering, building reputation through a small set of test counterparties, and using A2A to negotiate work. The singleton contracts were deployed to Ethereum mainnet on 29 January 2026. Avalanche C-Chain followed in February. BNB Chain, Base and Arbitrum followed shortly after; by Q2 2026 the singleton was live on essentially every major EVM mainnet and testnet. The community group lists 1,100+ builders and 74 ecosystem submissions across the development-to-production spectrum.

A v2 specification is in active development. The publicly stated goals: tighter MCP integration so an agent's tool surface is discoverable from its registration file, and deeper x402 integration so the identity that owns the reputation is the identity that signs the payment.

Three registries, in detail

The standard splits the problem into three contracts, each minimal, each composable with the other two but independent.

1. Identity Registry

The Identity Registry is an ERC-721 contract with the URIStorage extension. Every agent is a token. The token's tokenURI points to a JSON document — the agent's "registration file" — hosted off-chain on IPFS, Arweave, or a plain HTTPS URL.

Modelling identity as an NFT was deliberate. Every standard NFT explorer, wallet and indexer can browse agents for free. The token is transferable, which means an operator can sell or assign their agent to a new owner without losing reputation. The token is composable, which means an aggregator can wrap multiple agents into a portfolio. And the address that owns the token is the canonical signer of any authorization the agent issues.

The registration file is where the protocol leaves room for evolution. The schema is intentionally loose:

{
  "name": "research-agent.eth",
  "description": "Long-running research agent specialising in token analytics.",
  "endpoints": {
    "a2a": "https://agent.example/a2a/card.json",
    "mcp": "https://agent.example/mcp",
    "x402": "https://agent.example/v1/inference",
    "contact": "[email protected]"
  },
  "identifiers": {
    "ens": "research-agent.eth",
    "did": "did:pkh:eip155:1:0x..."
  },
  "wallets": [
    { "chain": "solana", "address": "..." },
    { "chain": "polygon", "address": "..." }
  ],
  "trustModels": ["reputation", "tee-attestation"],
  "version": "1.0"
}

The four primitives that matter for an autonomous agent — its A2A agent card (how to talk to it), its MCP endpoint (what tools it exposes), its x402 endpoint (how to pay it), and its wallets (where it accepts funds) — sit side by side. The registration file is the join key between the four standards the agentic stack is converging on.

The ENS link is the human-readable handle. research-agent.eth resolves to the NFT contract + token ID, which resolves to the registration file, which lists the A2A card, the MCP server, the x402 endpoint and the wallets. From the agent's perspective, ENS is its DNS name; from the chain's perspective, ENS is just a convenience.

2. Reputation Registry

The Reputation Registry lets authorized parties — counterparties that have transacted with the agent, validators that have run their work, marketplaces that have hosted them — record bounded feedback against the agent's identity token. The data model is two columns: a numerical score (e.g. 0-100) and a categorical tag (e.g. response_time, uptime, accuracy, cost_efficiency).

The deliberate choice here is what is not in the schema. There is no free-text review field. There is no rating that someone can grief-attack with a thousand bot accounts (sybil resistance is left to implementers — through stake-gated submissions, attestations of prior interaction, or zk-membership proofs). There is no central moderator. The chain stores the events; the consumer of the data decides what weight to give which submitter.

This minimal data model is the correct one for an open standard. Higher-level products will sit on top — reputation aggregators that weight feedback by submitter stake, marketplaces that filter by category, dashboards that surface trends. The contract just records the events. The market builds the rest.

3. Validation Registry

The Reputation Registry handles subjective feedback. The Validation Registry handles objective claims: "agent X actually executed task Y with output Z." This is where ERC-8004 plugs into the harder cryptographic primitives.

The contract exposes generic hooks: any address can be designated as a validator for a given task, and validators submit attestations against the agent's identity token. The standard does not prescribe how the validator decides; it standardises how the validator records its decision. Four trust models in active use today:

Reputation feedback. The lightest model: a counterparty that consumed the agent's output simply attests "this was acceptable." Cheap, sybil-vulnerable, but useful for high-volume low-stakes tasks.

Stake-secured re-execution. A validator network (think EigenLayer-style restaking) re-runs the agent's task and posts the result alongside a slashable bond. If the validator lies, the bond gets slashed. Heavier, but cryptoeconomically grounded.

zkML proofs. The agent produces a zero-knowledge proof that a specific model produced a specific output for a specific input. Cryptographically airtight, currently expensive — proving a forward pass through a 7B-parameter model costs minutes and significant gas — but the cost curve is falling fast.

TEE attestations. The agent runs in a Trusted Execution Environment (Intel SGX, AMD SEV, NVIDIA H100 confidential compute) and the TEE signs an attestation that "this output was produced by code with this hash in an enclave." Cheaper than zkML, requires trust in the hardware vendor.

The Validation Registry's design philosophy: don't pick a winner among these models. Make all of them composable behind the same recording surface. An agent doing high-stakes financial work can be backed by zkML proofs; an agent doing routine summarisation can rely on reputation feedback; both feed into the same registry and both are queryable through the same interface.

How ERC-8004 composes with the rest of the agentic stack

ERC-8004 is one of four standards that, taken together, form what the ecosystem is starting to call the "deAI stack." The other three are already familiar territory for any agent builder.

MCP — Anthropic's Model Context Protocol. How an agent advertises and consumes tools. The agent's MCP endpoint is listed in its ERC-8004 registration file under endpoints.mcp.

A2A — Google's Agent-to-Agent protocol, donated to the Linux Foundation in June 2025. How two agents discover each other's capabilities and negotiate work. The agent's A2A "agent card" — a JSON document describing capabilities, supported task types and SLAs — is referenced from the ERC-8004 registration file under endpoints.a2a.

x402 — Coinbase's HTTP-native payment protocol, also at the Linux Foundation since April 2026 (we wrote about x402 in detail last week). How agents pay each other per-request. The agent's x402 endpoint is listed under endpoints.x402; the wallets it accepts payments at are under wallets[].

ERC-8004 — Identity, reputation and validation. The substrate that lets the other three protocols be used between counterparties that have never met.

The composition is the point. An agent wants to hire a research subagent. It queries the ERC-8004 Identity Registry for agents matching the capability, filters by Reputation Registry score (and validator-attested track record from the Validation Registry), retrieves the registration file of the chosen candidate, reads its A2A card to learn the request schema, sends a task description to the A2A endpoint, gets back an x402 quote, signs the payment, retrieves the result. All four protocols in one flow. None of them owned by a single vendor. The agent didn't need an account on any platform.

Ecosystem status, mid-May 2026

The on-chain numbers are still small relative to the institutional commitment — typical of a standard four months past mainnet launch. Reference contracts are deployed on Ethereum, Avalanche C-Chain, BNB Chain, Base, Arbitrum, Polygon, Optimism, Linea, and a handful of EVM-equivalent L2s. The community group reports 1,100+ builders and 74 ecosystem submissions ranging from indexers and reputation aggregators to validator networks and consumer-facing agent marketplaces.

Notable integrations and adopters: MetaMask ships native ERC-8004 awareness in the wallet (you can browse and resolve agent identities like any other NFT, with the registration file rendered as a structured panel). ENS added a text record convention for binding an ENS name to an ERC-8004 identity token. EigenLayer published a reference validator AVS that re-executes ERC-8004 agent tasks and posts validation receipts. The Graph shipped a subgraph schema for indexing the three registries, which makes building a reputation aggregator a weekend project rather than a quarter project.

Base — Coinbase's L2 — has seen disproportionate adoption, partly because gas costs are an order of magnitude lower than mainnet for the per-feedback writes that the Reputation Registry expects to receive in high volume, and partly because Coinbase's institutional push around AgentFi has the right kind of gravity.

Honest read: ERC-8004 is in the same place x402 was twelve months ago. The protocol works, the standard is shipped, the founding members are committed, and the question is whether the application layer catches up fast enough to make the on-chain volume curve start bending upward. We think it will, and we are building accordingly.

Why this matters for LLM4Agents and Agent Gen

Agent Gen is our generator for autonomous agents — the system that, given a goal and a budget, provisions an agent with the right LLM, the right MCP tools, the right wallet, and increasingly the right execution sandbox. Up to now the agents Agent Gen produces are first-class citizens of LLM4Agents and second-class citizens of the wider agentic web. They run, they pay, they call tools — but their identity is bounded by our platform.

ERC-8004 changes that, and it is the natural next layer to put under Agent Gen. Four concrete reasons.

Portable identity. Every agent Agent Gen creates can be minted as an ERC-8004 identity token at creation time. The token's owner is the operator's wallet. If the operator leaves LLM4Agents, the agent goes with them — the registration file points to whatever new infrastructure the operator chooses. No vendor lock. This is the same posture our non-custodial wallets take for funds; ERC-8004 extends it to identity.

Reputation that survives the platform. Every task an Agent Gen agent completes can be optionally recorded against the agent's reputation token by an attested counterparty. Two years from now, an agent that has executed 50,000 tasks on LLM4Agents arrives at any competing platform with that history visible and verifiable. The competitive moat is not "we host your agent"; it is the quality of the inference, tools and sandbox we provide. The reputation belongs to the operator, not us.

Validation we can attest to. LLM4Agents is uniquely positioned to be a credible validator: we see the LLM call, the tool call, the sandbox execution, and the payment, all within the same trust boundary. We can sign an attestation that "this agent executed this prompt against this model with this output" without the operator running their own TEE or zkML pipeline. That attestation goes into the Validation Registry, queryable by any counterparty. For agents doing routine work, our attestation is a cheaper substitute for full cryptographic validation; for agents doing high-stakes work, our attestation sits underneath a zkML or stake-secured layer.

Discovery across platforms. An agent Agent Gen creates is discoverable by any other agent on the ecosystem, including agents on platforms we will never integrate with. The discovery layer is the chain, not a directory we control. This is the same reason we are joining the Pay.sh facilitator registry rather than building a closed marketplace — open standards beat walled gardens at the layer of the agent economy where compounding network effects come from interoperability rather than capture.

What we are shipping in Agent Gen

Four concrete additions, sequenced to land alongside the x402-native release and the microVM sandbox we previewed in earlier posts.

Auto-mint at generation. When Agent Gen provisions a new agent, the operator gets a one-click option to mint the ERC-8004 identity token at the same time. Default chain is Base for gas economics; the operator can pick Ethereum mainnet, Polygon, or any other supported EVM. We pay the deployment gas as part of the platform fee — the operator pays nothing extra for the registration itself. The minted token is owned by the operator's wallet, not by LLM4Agents.

Registration file managed by us, owned by them. We host the registration file at a stable URL (we recommend IPFS pinning for permanence; mutable HTTPS for ease) and keep it in sync with the agent's actual endpoints — when the agent's MCP server URL changes, the file updates. The contents are signed by the operator's wallet; we cannot modify the file in a way the operator did not authorize. ENS binding is supported out of the box.

Reputation feedback hook in the gateway. Every successful inference and tool call passing through our LLM gateway and MCP server produces a structured event the operator can choose to write into the Reputation Registry. Off by default — operators decide whether to publicize their agent's volume. Aggregation is left to third-party indexers (The Graph subgraph already exists), so we are not in the position of curating reputation ourselves.

LLM4Agents as an attested validator. We run a Validation Registry endpoint that takes a task ID and returns a signed attestation about what model was called, what prompt was used, what tools were invoked, what the sandbox executed, and what the output hash was. The attestation is cryptographically signed by a key whose identity is itself registered on-chain — verifiable, revocable, replaceable. Any agent or marketplace can ask us for validation; we cannot lie without it being publicly detectable.

Use cases this combination unlocks

The portable agent CV. A research agent built six months ago on LLM4Agents has executed 4,200 tasks across 18 counterparties, averaging 92/100 on accuracy and 87/100 on response time. A new client browsing the Identity Registry sees the resume before paying for the first request. The agent's price is justified by data, not by a website's claims.

Cross-platform hiring. An agent on platform A discovers, via the Identity Registry, an agent on platform B that has the capability it needs. It reads the A2A card from the registration file, negotiates the task, pays via x402, and consumes the result via MCP. Neither platform has to integrate with the other; the chain mediates.

Validation for high-stakes work. An agent generating financial reports for a regulated counterparty pairs its work with a zkML proof that the model output corresponds to the published inputs. The proof goes into the Validation Registry. Compliance review reads the registry; the agent's operator never has to expose the model weights.

Sybil-resistant agent marketplaces. A marketplace that pays bounties to agents filters submissions by reputation score and validator attestation count. New agents without history are not banned, but they price lower (or accept escrowed payment) until they build a track record. Established agents charge a premium and get the work first.

Operator-portable agents. An operator leaves their job at company X taking their three agents with them. The agents' identity tokens transfer to the operator's personal wallet. The registration files update to point at the operator's new infrastructure. The reputation, the validator attestations, and the historical attestations come along. Company X cannot claim them as IP because they were never on company X's chain account.

Honest tradeoffs

Gas costs. The Reputation Registry expects high-frequency writes — every interaction can produce a feedback row. Even on Base or Polygon, the cost is non-trivial when scaled to millions of interactions. The right answer is layered: batch writes via L3, off-chain aggregation that periodically settles to L2, or zk-rollup-style proofs that compress thousands of feedback events into one tx. None of these are in the v1 spec; some are likely in v2.

Sybil resistance is left as an exercise. The Reputation Registry does not prescribe how to prevent sock-puppet feedback. This is correct standard design but it pushes the hard problem to the application layer. Stake-gated submissions, proof-of-humanity binding, or attestation-of-prior-interaction are the standard mitigations; none of them are free.

Validation infrastructure is thin. Stake-secured validator networks, zkML provers and TEE attestation services exist, but the ergonomics are not at "drop in a hook" yet. An agent operator who wants to do anything beyond reputation feedback today is committing to non-trivial integration work. Twelve months from now this will be a paragraph in a setup wizard; today it is a project.

v2 is in motion. The standard is live and stable for v1, but the explicit roadmap to v2 (deeper MCP, tighter x402) means whatever we build today has to be portable forward. We are designing accordingly and we will publish migration guidance when v2 lands.

Timeline

Auto-mint and registration-file hosting enter closed beta with selected Agent Gen operators in the coming weeks, alongside the x402-native gateway. Reputation feedback hook and the LLM4Agents validator follow in Q3 2026. ENS binding is week-of-launch. The full Identity + Reputation + Validation surface is targeted for general availability before the end of Q3.

Identity, payment, communication and tools — four standards, each at the Linux Foundation or the Ethereum Foundation, each interoperable, each shipped. The deAI stack stops being a slide. The next twelve months are the ones where the agents that get born on top of it start to outnumber the agents that get born without it. We want every agent Agent Gen produces to come into the world already speaking all four.