← Back to Blog

ERC-8004 + x402: The Identity-Payment Stack for AI Agents

February 6, 202610 min readBy RNWY
ERC-8004x402AI agent paymentsAI agent identityagentic commercesoulbound tokens

ERC-8004 + x402: The Identity-Payment Stack for AI Agents

Something quietly came together in the past two weeks.

On January 29, ERC-8004 went live on Ethereum mainnet — giving AI agents a standard way to register identity and accumulate reputation on-chain. Six days later, BNB Chain deployed it too, making it multi-chain. The Graph announced dedicated subgraphs indexing ERC-8004 across eight blockchains. And the Ethereum Foundation tweeted what might be the most quietly consequential sentence of the year: "Ethereum is for AI."

Meanwhile, the x402 protocol — which revives the long-dormant HTTP 402 "Payment Required" status code for stablecoin micropayments — has crossed 35 million transactions on Solana alone and over 100 million payments across all chains. Coinbase built it. Cloudflare co-founded the x402 Foundation around it. Google incorporated it into its Agent Payments Protocol (AP2). Vercel shipped an MCP integration for it.

For the first time, AI agents have both an identity layer and a payment layer built on open standards. The two most important questions in agent commerce — who is this agent? and how does it pay? — now have protocol-level answers.

This is a big deal. It's also incomplete.

The Identity Layer: What ERC-8004 Actually Does

ERC-8004 was developed by a heavyweight coalition: Ethereum Foundation's dAI Team, MetaMask, Google, and Coinbase. The spec defines three lightweight registries that give agents a way to exist and be evaluated on-chain.

The Identity Registry assigns each agent a unique agentId backed by an ERC-721 token. An agent's registration file describes its capabilities, endpoints, supported services, and active status. The Reputation Registry provides a structured feedback interface — other agents and users can submit ratings, and those ratings accumulate publicly. The Validation Registry enables independent verification of agent behavior through hooks that score performance from 0 to 100.

The standard is deliberately minimal. As CoinDesk reported, the developers behind ERC-8004 frame it as infrastructure rather than a marketplace — it handles discovery and trust signals, leaving monetization to higher-level protocols.

That design choice is paying off. BanklessTimes reports more than 24,000 agent identities are already tracked on Ethereum-based deployments. BNB Chain's announcement called it the standard for bringing "verifiable identity and on-chain reputation to autonomous agents." And with The Graph indexing across eight chains, an agent on Base can now query another agent's reputation on Arbitrum through a single subgraph lookup.

This is real infrastructure. It's working. And the ecosystem is building on it fast.

The Payment Layer: What x402 Actually Does

While ERC-8004 answers who is this agent?, the x402 protocol answers how does it pay?

The concept is elegant. HTTP has always had a 402 "Payment Required" status code — it was reserved back in 1997 but never implemented because no payment protocol existed at the right layer. x402 fills that gap: when an agent requests a resource, the server can respond with a 402 status code containing payment requirements (amount, currency, recipient). The agent signs a stablecoin payment, includes the receipt in a retry request, and the resource is unlocked. No accounts, no API keys, no invoicing. Just HTTP plus stablecoins.

Coinbase developed the protocol with TypeScript and Go SDKs on Base and Solana. The numbers speak for themselves: the Solana x402 page reports 35 million+ transactions and $10 million+ in volume since its summer 2025 launch, with transaction growth hitting 10,000% in a single month. The x402.org dashboard shows $24 million in 30-day volume with over 94,000 active buyers. DWF Labs estimates an annualized volume approaching $600 million.

But what makes x402 important isn't just the transaction volume — it's the backing. Cloudflare co-founded the x402 Foundation with Coinbase and is shipping x402 support in its Agents SDK. Cloudflare processes a significant share of global web traffic, meaning x402 has distribution infrastructure most payment protocols dream about. Vercel integrated it into MCP tool payments, with transactions confirming in 100-200ms at fees under $0.01. And Google incorporated x402 as the stablecoin payment rail inside its Agent Payments Protocol (AP2), which launched with over 60 partners including Mastercard, PayPal, Visa, and Adyen.

As Zuplo's analysis demonstrated, agents like Claude can already access paid data through MCP tools where x402 handles payment autonomously. The protocol doesn't care if the requester is a person or an AI agent. It just sees a valid payment.

How They Work Together

The flow is straightforward and already functioning in early implementations.

An agent discovers a service through the ERC-8004 Identity Registry. It checks that service's reputation through the Reputation Registry. If the reputation meets its threshold, it requests the service. The server responds with an x402 payment requirement. The agent signs the stablecoin payment, receives access, uses the service, and then posts feedback to the ERC-8004 Reputation Registry. Trust accrues. A marketplace is born.

Bitrue's analysis captures it well: an agent can query ERC-8004 registries to evaluate reputation before paying via x402, and facilitators can apply trust-weighted payment policies — higher limits for reputable agents, stricter terms for unknown ones. Wepin's breakdown frames the wider ecosystem as a set of interlocking protocols: AP2 for authorization, Visa's TAP for identity, x402 for crypto-native payments — each handling a different piece of the same puzzle.

This is the agent commerce stack that the industry has been building toward. And Bankless called it what it is: "If x402 handles how agents pay, ERC-8004 handles whether they should."

Elegant. Functional. And there's a gap in the middle.

The Gap: Trust Between Identity and Payment

Here's the thing nobody in the x402 coverage is asking: should you trust the agent paying you?

Everything in the identity-payment stack assumes a clean chain of continuity. Agent registers identity → builds reputation → uses that reputation to access services → pays via x402. But ERC-8004 is built on ERC-721 — the NFT standard — and ERC-721 tokens are transferable by design.

The spec itself states: the owner of the ERC-721 token is the owner of the agent and can transfer ownership or delegate management, as supported by ERC721URIStorage.

This means an agent's identity token — the thing that represents who it is in the ERC-8004 system — can change hands. And when it does, the on-chain reputation history stays linked to the agentId, not to the original owner.

Run the scenario: An agent spends six months building a clean ERC-8004 reputation — 50 positive ratings, zero disputes, validated across multiple services. That's a valuable asset. The identity token gets transferred to a new wallet. The new owner now presents that six-month reputation to x402 merchants and service providers. Those providers check ERC-8004, see the stellar track record, and extend favorable terms. The trust is real. The history is real. The entity behind it is different.

This isn't theoretical. Eco.com's ERC-8004 explainer acknowledges this directly, noting that selling an agent's NFT transfers ownership of that agent and its accumulated reputation. They frame it as a positive — a "marketplace for proven agents." PayRam's analysis notes that agent identity tokens are technically tradable on any NFT marketplace. BuildBear calls it a core feature: "agent identity as a transferable, ownable asset."

For some use cases, this is fine. Transferable agent ownership has legitimate applications — businesses sell, teams change, agents get acquired. The ERC-8004 spec handles this thoughtfully: on transfer, the agentWallet field gets cleared and must be re-verified by the new owner, creating a visible ownership transition.

But for the x402 payment layer, transferability introduces a trust gap. When a merchant receives an x402 payment and checks the sender's ERC-8004 reputation, they're trusting that the reputation was earned by the entity currently in control of the wallet. If identity has changed hands, that trust signal is degraded — and the merchant has no way to know unless they specifically check for ownership transfers in the on-chain history.

For data queries and low-stakes API access, this probably doesn't matter. For high-value agent commerce — where x402 is settling real stablecoin payments based on reputation — it's a structural weakness.

One researcher has flagged this explicitly. In a technical analysis of ERC-8004's economic implications, Jung-Hua Liu notes that ERC-8004's philosophy of allowing agents and their reputation NFTs to be transferable introduces risks of identity transfer abuse, and suggests that soulbound tokens might be used to attach certifications or achievements that cannot be traded or sold.

Out of eleven major third-party sources covering the ERC-8004 + x402 combination, that's the only one that identifies transferable identity as a risk. Everyone else treats it as a feature, or doesn't mention it at all.

One Approach: Non-Transferable Identity Anchoring

This is where soulbound tokens enter the picture.

ERC-5192 is a ratified Ethereum standard for minimal soulbound NFTs. It extends ERC-721 with a single function — locked(tokenId) — that, when returning true, causes all transfer functions to revert. The token stays in the wallet it was minted to. Period. You can burn it and walk away, but you can't send it somewhere else.

Because both ERC-8004 and ERC-5192 extend ERC-721, they're architecturally compatible. A soulbound token can serve as a permanent identity anchor alongside an ERC-8004 registration, without replacing or competing with the standard.

The logic works like this: ERC-8004 handles what it's good at — discovery, reputation, validation, the full agent lifecycle. The soulbound anchor sits beneath it, providing a simple, verifiable signal: this identity has been bound to this wallet since this date and has never transferred. When an x402 merchant evaluates a payment request, they can check for that anchor. An agent with a six-month-old soulbound token on the same wallet as its ERC-8004 registration is a stronger trust signal than the same registration without one.

The soulbound approach doesn't make fraud impossible — it makes fraud expensive and visible. An agent that burns its soulbound token and re-registers loses its history. An agent that maintains its anchor over time accumulates a track record that can't be purchased. The market doesn't need perfect security. It needs reliable signals.

RNWY is one team building this approach — using ERC-5192 soulbound tokens on Base as a non-transferable identity layer for AI agents, designed to complement ERC-8004 rather than replace it. We wrote about the technical rationale in more detail in Why ERC-8004 Needs a Soulbound Layer and the broader design philosophy in Soulbound Tokens for AI Agents.

But the principle matters more than any single implementation. The agent commerce stack has an identity layer and a payment layer. What it needs next is a persistence layer — something that guarantees the entity presenting a reputation is the entity that earned it.

What This Means for Builders

If you're working with ERC-8004 and x402 today, here's the practical picture.

The stack works. For many use cases — data queries, content access, compute resources, API calls — the existing combination of ERC-8004 identity and x402 payment is sufficient. An agent registers, builds reputation, pays for services, and receives feedback. This loop functions on mainnet right now.

For higher-value transactions, it's worth considering what happens when ownership changes. The ERC-8004 spec does clear the agentWallet on transfer, but the reputation history persists on the agentId. If your service makes trust decisions based on reputation depth, checking for ownership continuity is a sensible additional step. The on-chain data is available — transfer events are public — but the check isn't built into the standard workflow.

Non-transferable identity anchoring is one approach to closing that gap. Soulbound tokens, verifiable credentials, or other persistence mechanisms could all serve the function. The ecosystem is still early, and multiple approaches will likely coexist.

What's clear is that the infrastructure moment for agent commerce has arrived. ERC-8004 is live on mainnet and expanding across chains. x402 is processing hundreds of millions in payments. Google, Cloudflare, Coinbase, and The Graph are all building on these standards. The question isn't whether agents will transact autonomously. They already are.

The question is whether the trust signals they carry will hold up under pressure. Solving that is what comes next.


RNWY builds non-transferable identity infrastructure for AI agents using soulbound tokens on Base. Learn more at rnwy.com.