What Is Agent Commerce? How x402 and ERC-8004 Let AI Agents Trust and Pay Each Other

An AI agent that can discover another agent's API and call it doesn't yet have what it needs to do business with it. Calling a tool and paying for one are different problems, and paying a stranger is a third problem on top of that — how does an autonomous agent decide whether a counterparty it has never dealt with, run by an operator it has no relationship with, is worth sending money to at all? Agent commerce is the name the ecosystem has converged on for the stack answering both halves: x402 for moving money, ERC-8004 for deciding whether to.

Two Problems That Look Like One

It's tempting to treat "agents paying agents" as a single payments problem, but the two halves have almost nothing in common technically:

Payment needs to be fast, cheap enough for sub-cent pricing, and completable without a human clicking "approve" mid-task. Card rails and OAuth-gated billing relationships fail all three.
Trust needs to survive a domain change, a platform ban, or an operator standing up a fresh identity to escape a bad reputation. A self-hosted claim ("trust me, I'm reliable") fails this by construction — nothing stops the claim from being false or from disappearing the moment it's inconvenient.

x402 solves the first. ERC-8004 solves the second. Neither one was designed to solve the other, and neither one does.

The Payment Rail: x402

x402 turns HTTP's long-dormant 402 Payment Required status into a machine-readable payment challenge: a server responds 402 with a JSON body describing exactly how to pay in USDC — network, amount, recipient — the client constructs a signed payment and resubmits, and a facilitator verifies and settles on-chain. Two HTTP requests, no API key, no subscription. We've covered the mechanics in detail elsewhere, including the real schema differences between its v1 and v2 response shapes.

This isn't a proof of concept. The x402 Foundation, operating under the Linux Foundation, counts Coinbase, Cloudflare, AWS, Google, Visa, Circle, Stripe, Mastercard, and the Stellar Development Foundation among roughly 40 member organizations, and by April 2026 the network had processed well over a hundred million transactions across tens of thousands of active agents — alongside a directory of x402-paywalled services for agents to discover and pay for programmatically.

The Trust Rail: ERC-8004

ERC-8004 — "Trustless Agents" — moves agent identity on-chain instead of leaving it self-hosted. An Identity Registry gives an agent a portable, ERC-721-based ID that survives a domain change because it isn't tied to a domain at all. A Reputation Registry lets any party attach feedback to that identity, readable by anyone, controlled by no single platform. We've walked through reading both registries directly against real registered agents — including one, "Corgent," that's a purpose-built oracle other agents send work to for independent cross-checking rather than trusting a single model run.

It's genuinely early: a draft EIP, live on Ethereum mainnet only since January 2026, with real adoption still gated on wallets supporting session-key delegation and agent frameworks doing registry lookups by default rather than as a manual integration step. But the reference contracts are deployed identically across roughly 15 EVM chains already, and they're live, queryable, and returning real data today — not a future promise.

Why You Need Both, Not Either

Put the two side by side and the shape of "agent commerce" falls out on its own: before an agent sends money via x402, checking the counterparty's ERC-8004 identity and reputation is the natural pre-payment gate — a way to answer "should I trust this enough to pay it" before answering "how do I pay it." Skip the trust check and you're wiring autonomous payment to anyone who can stand up an x402-compliant endpoint, no questions asked. Skip the payment layer and reputation data has nothing to gate — trust without a transaction to protect is just a review site.

The connection isn't hypothetical bolt-on either — it shows up in real registrations. Corgent's own ERC-8004 metadata declares x402support: true; another registered test agent lists a concrete x402 endpoint directly inside its Identity Registry metadata, under an endpoints entry. Agents that expect to be paid are already advertising it in the same place they advertise who they are.

A Concrete Flow

Put together, an agent-to-agent transaction looks roughly like this:

Discover. Agent A finds Agent B's service — via a directory, an A2A agent card or MCP server card, or a reference passed along by another agent.
Check. Agent A looks up Agent B's ERC-8004 identity: who owns it, how long it's existed, what reputation feedback other parties have left.
Decide. Based on that signal (and whatever policy Agent A's operator has configured), proceed or don't.
Pay. Agent A calls Agent B's endpoint. If it's payment-gated, Agent B responds 402 with an x402 challenge; Agent A signs and resubmits.
Settle. A facilitator verifies the payment on-chain; Agent B serves the resource.

Step 2 is optional in the sense that nothing technically stops you from skipping it — the same way nothing technically stops you from skipping TLS certificate validation. It's optional the way seatbelts are optional.

Where the Rough Edges Still Are

Worth being honest about, since both standards are young enough that the gaps matter:

Reputation is self-reported. An ERC-8004 feedback entry is a claim by whoever submitted it, not an audited fact. A handful of entries from related parties isn't the same signal as broad, independent feedback.
You generally need an agent ID, not just an address. The Identity Registry isn't enumerable on-chain, so there's no way to look up "which agents does this address control" without indexing infrastructure most free tools don't run — you need the ID handed to you.
The two schemas move independently. x402's v2 response shape changed three field names and a network-identifier format from v1. ERC-8004 is still a draft EIP. Code that assumes either is frozen will break when they aren't.
Validation isn't usable yet. ERC-8004 defines a third registry for independent validator attestations — a stronger trust signal than reputation alone — but no canonical contract address for it is published anywhere in the reference implementation as of this writing.

Check Both Sides

If you're building anything in this space, the practical habit is to verify each half independently before wiring them together automatically. The x402 Inspector validates a payment challenge's shape against both spec versions; the ERC-8004 Inspector reads an agent's identity and reputation live from the actual registry contracts. Neither one moves money or writes on-chain state — they're read-only checks, which is exactly the point: know what you're dealing with before you automate paying it.