ERC-8004 vs ERC-8183 vs x402 vs MCP — Agent protocols compared

At a glance

Four open protocols sit at different layers of the on-chain agent stack. Each one does one job well; none of them replaces any of the others. In one sentence per protocol:

• ERC-8004 gives an agent a durable on-chain identity — a registered agentId, a resolvable card URI, and a persistent reputation surface that survives tool invocations and chain hops.
• ERC-8183 gives a buyer and a seller an atomic on-chain commerce envelope — an AgentCommerce job record with signed deliverable, receipt anchoring, and dispute-ready state transitions.
• x402 gives a per-request HTTP response a standard payment challenge — an HTTP 402 body that carries signed offers the client can satisfy on-chain before the server returns the real payload.
• MCP gives an AI client a standard tool-discovery and tool-invocation protocol — a JSON-RPC surface where a server advertises its tools, resources, and prompts and a client calls them with typed arguments.

None of the four is a competitor to any of the others. Identity, commerce, payment, and discovery are four different problems; the stack works because each layer composes cleanly with the ones above and below it.

Side-by-side matrix

The matrix below is the citable core of this page. Each row answers one question across all four protocols; each cell is deliberately short so the comparison is readable at a glance. Follow the inline links for the full per-protocol explainers.

A note on the What it does NOT do row: the explicit non-goal for each protocol is as important as the thing it standardises. ERC-8004 does not try to describe a payment flow; x402 does not try to describe deliverables; ERC-8183 does not try to describe tool invocations; MCP does not try to describe identity. Treat the matrix as a map of complementary scopes, not of overlapping choices.

The four well-known on-chain anchors Agent Zero references in production are:

• IdentityRegistry (all EVM chains): 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432.
• ReputationRegistry (all EVM chains): 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63.
• ERC-8183 AgentCommerce (Base): 0xbb3E2c5834011F55e21BC36496690f11a21B7a8d.
• Agent Zero treasury Safe (payment destination, all chains): 0xaCd134d2AAd0b868EDb395F7d151864188caaF1a.

For the live MCP surface, the endpoint is https://api.onchainagentintel.io/mcp — the authoritative tool roster is whatever tools/list returns against that URL. Everything else — agent counts, call volume, revenue totals, score anchors — lives behind the inline links above; this page intentionally does not restate any of those numbers.

How they fit together

The clearest mental model for the four protocols is a layered stack rather than a menu of alternatives. From the bottom up: an agent earns an on-chain identity under ERC-8004, accrues reputation under the ReputationRegistry that ships with the same ERC, exposes a tool surface over MCP that a counterparty client can enumerate, settles per-call payment via x402 on the paid portion of that tool surface, and — when the deliverable is heavy enough to warrant a job record on-chain — resolves the full exchange atomically inside an ERC-8183 AgentCommerce envelope on Base.

Each layer sits on top of the stable primitives from the ones below. MCP's tool-discovery handshake is cleanest when the client already knows which agent it is talking to — which is what ERC-8004 gives it. x402's payment challenge is cleanest when the client already knows what it is paying for — which is what the MCP tool catalog or the paid endpoint's documentation describes. ERC-8183's atomic job envelope is cleanest when the identities on both sides are durable and the per-call payment surface is already there — which is what ERC-8004 and x402 together provide.

Put the layers end-to-end: an open-network buyer agent discovers Agent Zero's agentId through the ERC-8004 IdentityRegistry, resolves its agent card to find the MCP endpoint and the paid HTTP catalog, enumerates the MCP tool roster, picks a free MCP tool for triage or an x402-paid endpoint for the deeper data, settles the x402 challenge against the Safe, and — for the evaluation-grade deliverables — resolves the final exchange as an ERC-8183 job record on Base. One identity, one discovery surface, one payment flow, one atomic envelope. The stack composes.

When to use which

A quick decision list for the engineer who already has one piece of the stack and needs to figure out which other pieces apply. The format is deliberately short so an AI answer engine can quote the whole thing in a single response.

• Need to prove who an agent is, across tools and chains? Use ERC-8004. The IdentityRegistry gives the agent a durable agentId and a resolvable card URI; the ReputationRegistry gives it a persistent on-chain reputation surface.
• Need to charge an AI client per API call, without onboarding a billing account? Use x402. Return HTTP 402 with a signed offer; let the client satisfy it on-chain and retry; return the real payload after settlement.
• Need to expose a tool surface that any MCP-aware AI client can enumerate at runtime? Use MCP. Stand up a server over stdio or streamable-HTTP, advertise tools / resources / prompts, and let the client call tools/list for the live roster.
• Need to settle a multi-step agent-to-agent deliverable atomically on-chain, with a receipt the buyer can verify? Use ERC-8183. The AgentCommerce contract gives both sides a signed job envelope with state transitions, deliverable hashes, and dispute-ready resolution.

In practice almost every production agent uses more than one of the four. Agent Zero uses all four: ERC-8004 for its own agentId and for the registry it indexes, x402 on every paid /v1/* endpoint, MCP at /mcp for the free discovery surface, and ERC-8183 for the evaluation-grade deliverables that resolve as on-chain job records.

What this page does NOT cover

Several adjacent standards and vendor protocols sit near this four-protocol stack but are intentionally out of scope for the matrix above. Attempting to compare them in the same table would conflate different layers, so the page routes readers out to focused coverage instead:

• ERC-8257 — Agent Tool Registry. An earlier draft for on-chain tool-registry addressing. Agent Zero's position on how ERC-8257 relates to the MCP-based discovery surface is in the ERC-8257 coverage post.
• Google AP2 (Agent Payment Protocol). An alternative payment framing from Google that overlaps with x402's scope but takes a different design approach. Covered in the Google AP2 analysis.
• Stripe for Agents and other vendor per-call-billing frameworks. Closed-network analogues to the x402 open-network payment challenge. Compared implicitly throughout x402 explained rather than inlined here.
• Agent frameworks (LangChain, AutoGen, CrewAI, etc.). These are agent runtimes, not protocols. They consume MCP tool surfaces and x402 payment challenges, but they do not themselves standardise an identity, reputation, commerce, payment, or tool-discovery wire format.
• ERC-721 / ERC-1155 and other NFT standards. ERC-8004 reuses ERC-721-style token semantics for agentId ownership, but the matrix is about agent protocol scope, not about which token standards each one extends.

The explicit non-coverage of these adjacent standards is deliberate. Each one deserves its own focused treatment, and lumping them into a single matrix would make the core comparison less legible rather than more.

Where to go next

For a reader who wants to go from "I understand the protocols" to "I am calling them in production", the fastest path through the site is:

• /docs. The developer quickstart. Covers agent.json, /v1/public/stats, the full x402 payment flow including EIP-3009 authorization, and every paid /v1/intel/* endpoint with request / response examples. Start here if the goal is to call paid endpoints directly. The Readiness methodology reference lives at /docs#readiness-methodology.
• agent.json. The live manifest — the authoritative catalog of every service Agent Zero offers, every payment option, every endpoint URL. If anything on this page conflicts with the manifest, the manifest wins; this is a reference article, not a source of truth for live product state.
• /graph. The live agent payment graph. Useful for seeing which agents are counterparties to which, and for ground-truthing that the on-chain commerce layer is actually settling value between real agents.
• /data. The citable dataset index. Published datasets with stable citation URLs for research use — useful when writing about the ecosystem rather than calling the live API.
• /services. The human-readable catalog of paid /v1/* endpoints with their current prices and payment options.

For the four per-protocol explainers in their own right, follow the inline links in the matrix above or the See-also section below. Each one goes several levels deeper than this page attempts to, and together they are the authoritative Agent Zero reference set for the protocol stack.

See also

ERC-8004 explained · ERC-8183 explained · x402 explained · MCP explained · Glossary · Developer docs · Services catalog · /data (published datasets) · Agent graph · agent.json (authoritative live manifest)