All posts
· 10 min read ·

The agent payments 'war' is actually a stack — and there's nothing at the bottom

x402, AP2, ACP, and Visa's TAP are described in the trade press as competing protocols. The primary specs say otherwise — they compose into layers. The interesting gap is the one no layer covers.

Every few weeks a new piece appears framing agent payments as a winner-takes-all contest: Coinbase's x402 versus Google's AP2 versus Stripe's ACP versus Visa's TAP, the implied subtitle being "who will own AI commerce."

Read the primary specs and the picture inverts. The protocols don't compete; they stack. An agent paying for a SaaS API call can use AP2 to prove the user authorized the spend, A2A to negotiate with the merchant agent, and x402 to settle the actual transfer — and the documentation for each protocol explicitly assumes the others are doing their job at adjacent layers. The interesting observation isn't which one wins. It's that the stack, taken together, has no answer to a basic question: which agent is signing the mandate.

Scaffolding rising against a structure under construction — the layered, partially-finished shape of an infrastructure stack. Photo: Jackson Allan on Unsplash.

The layers, as the specs describe themselves

The clearest statement comes from AP2's own documentation, which describes the protocol as "available as an extension for the open-source Agent2Agent (A2A) protocol" and ships reference samples for both card-based settlement and x402 settlement. AP2 doesn't replace A2A or MCP; it slots in above them and below the settlement rail.

The settlement rail itself is where x402 sits. x402 is a payment transport — it revives the HTTP 402 status code so that a server can demand a stablecoin payment in response to a request and the client can attach a signed payment to the next attempt. There is no notion of intent, consent, or audit trail in x402; those are out of scope. Coinbase reported 50 million transactions across the protocol by early 2026, almost all of them machine-to-machine micropayments where the "user authorized this" question is either trivial or absent.

AP2 was announced in September 2025 explicitly to fill the layer above. Its core primitive is the mandate — a verifiable-credential-signed digital contract that captures user intent and, later, the cart that intent resolved into. AP2 is payment-agnostic; it does not move money. It records and proves that the user told the agent to spend it. The protocol's three stated goals are authorization, authenticity, and accountability, none of which are settlement.

Stripe's ACP and Visa's TAP sit elsewhere on the same plane. ACP is a merchant-side checkout protocol with Stripe's existing payment relationships behind it; TAP is Visa's answer to the same authorization problem AP2 addresses, scoped to card networks. They are competitive with each other in the way that Stripe and Visa have always competed, not with the stack as a whole.

Drawn as a stack, with the layers labelled by the question each one answers:

The agent payment stack A vertical stack of five layers. From top: Transport (x402), Authorization (AP2, TAP), Merchant checkout (ACP, UCP), Agent coordination (A2A, MCP). The bottom layer — Identity — has no protocol and is shown with a dashed outline. THE AGENT PAYMENT STACK Transport / settlement x402 Authorization / audit AP2, TAP Merchant checkout ACP, UCP Agent coordination A2A, MCP Identity — no protocol

The same picture, with the detail per row:

Layer Concern Protocol(s)
Transport / settlement Move money x402, traditional rails
Authorization / audit "Did the user say to do this?" AP2, TAP
Merchant checkout "Is this a real cart with real prices?" ACP, UCP
Agent coordination "Which agent is talking to which agent?" A2A, MCP
Identity "Which agent is this, and can we trust it?" —

The bottom row is the load-bearing one. None of the four payment protocols specifies it. A2A 1.0 — released by the Linux Foundation on April 9, 2026 with "Signed Agent Cards for cryptographic identity verification" — gets closer than the others, but a signed card answers "this card was signed by this key," not "this key belongs to an agent you have any reason to trust."

Why the gap is structural, not temporary

The omission isn't an oversight that the next spec revision will fix. Each protocol in the stack delegates identity to the layer below it, and the layer below it delegates the same question further down, until the stack runs out of layers.

This is the same pattern that produced the certificate-authority ecosystem on the web: at some point a layer above PKI had to decide which roots to trust, and the answer became a system of audited CAs and Certificate Transparency logs. Agents are arriving at the same architectural moment, and the candidates for the "root trust" layer are still being prototyped in parallel:

  • ERC-8004, the Ethereum Improvement Proposal authored by Marco De Rossi and others, proposes three on-chain registries — Identity, Reputation, Validation — and went live on Ethereum mainnet on January 29, 2026.
  • AGNTCY's OASF, governed under the Linux Foundation AGNTCY project, defines a schema for agent capabilities used as a discovery primitive.
  • MCP server registries, now coordinated under the Agentic AI Foundation formed in December 2025, are converging on signed publication but have not yet adopted a single transparency-log model.

None of these is itself a complete identity layer. ERC-8004 provides a handle and a place to attach reputation; it does not verify that the agent at that handle responds, serves a valid card, or behaves the way the registry claims. OASF provides a schema; it does not provide a probe. MCP registries provide publication; they do not yet provide continuous conformance evidence.

The payment-stack diagram, drawn honestly, has a missing-basement problem.

What this means for builders

If you're shipping an agent that pays for things, the practical implication is that you cannot get end-to-end trust by adopting any single protocol from the list. The payment stack will validate that some key signed some mandate. Whether the agent on the other end of A2A is the agent you think it is — that question lives in a different layer, and that layer is still being written.

This is the layer Agenstry works on. Specifically, the question "does the agent at this address actually exist, serve a valid card, and conform to the spec it claims to implement" is a live-probe question, not a registry-lookup question. A registry can record that an agent claimed to be MCP-compliant on the day it published. A probe is what tells you it still is.

The interesting work over the next six months is whether the three identity-adjacent efforts — ERC-8004 on-chain handles, OASF capability schema, MCP/A2A registry consolidation under AAIF — converge into something that plugs cleanly into the bottom of the payment stack.

What we're watching

Three concrete things, all observable in the next two quarters:

  1. Whether AAIF's hosted MCP registry adopts a transparency-log model — the CT-for-agents analogue — or stays as a publication-only directory. The difference matters for downstream protocols that want to verify the registry's claims rather than trust them.
  2. Whether AP2 v0.3 or later names a specific identity provider for the agent side of its mandate signature, or continues to leave that question to the integrator.
  3. Whether ERC-8004's reputation registry attracts enough independent validators to produce signal that survives without a probing layer. Reputation that derives entirely from self-reported feedback collapses into the same problem registries already have.

The payment-protocol coverage will keep framing this as a competition. The specs themselves are clearer: it's a stack with a hole at the bottom.

Sources

← Back to blog Agenstry