05 — Protocol Deep Dive: x402, ERC‑8004 and the Crypto Stack for Agentic Payments

Part of the Agentic Payments research report. Cross‑references: Google AP2 in 03-protocol-deep-dive-ap2.md; OpenAI/Stripe ACP in 04-protocol-deep-dive-acp.md; card‑network rails in 06-card-networks.md; wallets/platforms in 07-wallets-platforms.md; security and trust in 09-security-and-trust.md.

1. Why crypto rails for agents

Most of this report is about how the incumbent payments stack — card networks, bank rails, wallet platforms — is being retrofitted for autonomous software. This section covers the other half of the story: a parallel stack, built on public blockchains and stablecoins, that was designed from the outset for programmatic, machine‑to‑machine (M2M) transactions. Advocates frame it as the "native" rail for the agent economy; critics note that it inherits all the regulatory, volatility and UX problems crypto has always had. Both claims are true at the same time, and the honest version of the story is that the crypto stack and the card stack are converging — agent wallets issue cards, card networks route over stablecoins, and protocols like Coinbase's x402 are deliberately rail‑agnostic.

Before diving into protocols, it is worth stating precisely why builders keep reaching for crypto when designing for agents. Five reasons recur in the primary documentation:

1.1 Programmability by default. Stablecoins such as USDC are ERC‑20 tokens whose transfer logic is an on‑chain smart contract. Any condition that can be encoded in Solidity — spending limits, merchant allow‑lists, multi‑sig approvals, time locks, revocable authorisations — can be enforced by the rail itself rather than by a platform. ERC‑20 extensions like EIP‑3009 (transferWithAuthorization) and Permit2 let a user sign an off‑chain authorisation that any relayer can submit on‑chain, which is exactly the shape needed for a delegated agent payment[^1].

1.2 Composability. A payment on a public chain is a piece of state other smart contracts can read. An agent can pay for an API call, receive a signed receipt, and pass that receipt to a second contract that releases a dependent payment — all without a central coordinator issuing webhooks. This is the property that makes "DeFi‑native" agents imaginable.

1.3 24/7 settlement and global reach. Public chains do not close on weekends, do not observe bank holidays, and do not impose cut‑off times. For an agent operating across time zones, "settlement in the next batch" is a UX failure; for a stablecoin transfer on Base or Solana, final settlement is seconds to minutes.

1.4 No agent‑level KYC. A public‑chain wallet is a keypair. It does not require a name, a Social Security number, or a bank relationship. That is a compliance problem for some use cases and a feature for others: an autonomous crawler paying fractions of a cent per page does not plausibly fit into existing customer‑identification frameworks, and existing rails simply will not authorise a $0.001 charge per HTTP request. (This is why compliance‑oriented schemes like Skyfire's "Know‑Your‑Agent" and ERC‑8004's Identity Registry are layered on top of the payment rail rather than built into it.)

1.5 Micropayment economics. On Base and Solana, the marginal cost of a USDC transfer is fractions of a cent; with EIP‑3009 relaying, the payer may incur no gas cost at all. That opens a design space — per‑request, per‑token, per‑frame billing — that card networks, which typically have interchange floors well above $0.05, cannot economically serve[^2].

These five properties are the substrate. The protocols below are attempts to turn that substrate into something an HTTP server or an LLM can actually use.

2. x402 — HTTP‑native payments for agents

2.1 Reviving HTTP 402

The HTTP 402 Payment Required status code was reserved in RFC 7231 for future use and never standardised[^3]. Coinbase's x402 protocol, announced on 6 May 2025, finally puts semantics behind the status code: when a resource server returns 402, it simultaneously returns a machine‑readable description of what payment it will accept, and a compliant client can pay and retry the same request without any human in the loop[^4].

The tagline on x402.org is accurate to the spec: "x402 is an open, neutral standard for internet‑native payments."[^5] The project's marketing dashboard claims 75.4M transactions, $24.2M volume, 94,060 buyers and 22,000 sellers in the trailing 30 days as displayed on x402.org in April 2026; these are self‑reported and should be treated as marketing figures rather than audited metrics[^5].

2.2 The wire protocol

x402 version 2 defines three HTTP headers (introduced on top of the standard status code)[^6]:

Header Direction Payload
PAYMENT-REQUIRED Server → Client Base64‑encoded PaymentRequired JSON
PAYMENT-SIGNATURE Client → Server Base64‑encoded PaymentPayload JSON
PAYMENT-RESPONSE Server → Client Base64‑encoded SettlementResponse JSON

The PaymentRequired object lists one or more accepts entries. Each entry is a (scheme, network, asset, amount, payTo, …) tuple — so a single endpoint can simultaneously accept, for example, "exactly 0.01 USDC on Base" and "exactly 0.01 USDC on Solana", and the client picks the rail it prefers. Payment details are Base64‑encoded for HTTP header compatibility, which also means they can be shipped through proxies and CDNs that are strict about header characters[^6].

2.3 Facilitator architecture

x402 deliberately separates three roles:

  • Client (the buyer — often an agent) holds keys and can sign payment authorisations.
  • Resource server (the seller) gates a URL with 402 and decides whether to accept a payment proof.
  • Facilitator is an optional service that offers /verify and /settle endpoints: it validates a signed payload against on‑chain state and, if accepted, submits the transaction itself[^7].

Crucially, the facilitator is not a custodian. Funds move directly from the buyer's wallet to the seller's payTo address via an on‑chain function like transferWithAuthorization; the facilitator only ever signs its own gas‑paying transaction that carries the client's pre‑signed authorisation. The x402 docs explicitly state: "The facilitator does not hold funds or act as a custodian — it performs verification and execution of onchain transactions based on signed payloads provided by clients."[^7]

This yields a trust model that is palatable both to the crypto‑native ("no intermediary can steal") and to the CFO ("our payments team can outsource chain connectivity without outsourcing custody").

2.4 Schemes: exact, upto and deferred

An x402 scheme is a pattern for constructing and verifying a payment payload. The reference schemes are:

  • exact — the buyer signs an authorisation for an exact amount. The canonical EVM implementation uses EIP‑3009's transferWithAuthorization on a stablecoin that supports it (USDC is the reference asset). The facilitator submits the pre‑signed message; the chain executes the transfer atomically. exact is the only scheme shipped in x402 v1 and is the dominant one in production[^8].
  • upto — the buyer signs an authorisation for an upper bound, and the server captures up to that amount. This is the analogue of a card authorisation/capture split and is useful when the final price is unknown at request time (e.g. a metered API whose cost depends on input size).
  • deferred — a newer scheme proposed jointly by Coinbase and Cloudflare in September 2025 alongside the formation of the x402 Foundation. It decouples the cryptographic handshake from settlement: the client presents a signed commitment, the server grants access immediately, and settlement happens later in aggregate — via batch stablecoin settlement, via a card on file, or via a pre‑negotiated licence. The motivating use case is Cloudflare's "pay per crawl", where a bot crawls thousands of pages and settles once at the end of the day[^9].

The protocol is deliberately designed so that additional schemes (e.g. subscription, lightning‑style routed payments, fiat rails) can be added without a breaking change; scheme is just a string that both sides must understand.

2.5 Supported chains and assets

As of April 2026, the x402 docs and GitHub indicate live facilitators for Base, Solana, Polygon, and Avalanche, with reference SDK packages for EVM (@x402/evm), Solana (@x402/svm), and Stellar (@x402/stellar); an ecosystem list on x402.org/ecosystem is the canonical registry for third‑party facilitators[^10]. The dominant settlement asset in production is USDC, with a long tail of other stablecoins supported per facilitator.

2.6 Gas sponsorship and fees

One of the core design goals is that the buyer should not need to think about gas. Because EIP‑3009 lets any relayer submit a signed authorisation, the facilitator pays the gas in its own native asset (ETH on Ethereum/Base, SOL on Solana) and is compensated — if at all — via a fee baked into the payment scheme or an out‑of‑band pricing agreement.

The protocol itself charges zero protocol fees; the x402 Foundation repeatedly emphasises this as a design value[^11]. Coinbase Developer Platform (CDP) runs a hosted facilitator and, per the x402 repository and Coinbase's developer marketing, sponsors gas on Base up to a limit per registered developer, making the first thousand or so transactions per month effectively free for many testbed deployments; developers should consult CDP's current pricing page before assuming any specific allowance remains in force[^12].

2.7 SDKs and integration surface

The TypeScript reference packages split the protocol across core (@x402/core), chain backends (@x402/evm, @x402/svm, @x402/stellar), client transports (@x402/fetch, @x402/axios), and server middleware for common frameworks (@x402/express, @x402/hono, @x402/next, @x402/fastify)[^13]. Python (pip install x402) and Go (go get github.com/x402-foundation/x402/go) ports exist as reference implementations[^13]. The "one line of code to accept payments" tagline is not quite hyperbole:

app.use(
  paymentMiddleware({
    "GET /weather": {
      accepts: [{ scheme: "exact", network: "base",
                  asset: "USDC", amount: "10000", payTo: "0x..." }],
      description: "Weather data",
    },
  }),
);

Cloudflare has shipped first‑class x402 integration in its Agents SDK and in its MCP offering, so a Cloudflare Worker can gate an MCP tool with x402 without running any crypto infrastructure itself[^14].

2.8 Flow diagram

sequenceDiagram
    autonumber
    participant A as Agent / Client (buyer)
    participant S as Resource Server (seller)
    participant F as Facilitator (e.g. CDP)
    participant C as Chain (e.g. Base)

    A->>S: GET /resource
    S-->>A: 402 Payment Required + PAYMENT-REQUIRED header
(accepts: exact, base, USDC, 0.01, payTo=0x...)
    A->>A: Sign EIP-3009 transferWithAuthorization payload
    A->>S: GET /resource + PAYMENT-SIGNATURE header
    S->>F: POST /verify {payload, requirements}
    F-->>S: verified: true
    S->>F: POST /settle {payload, requirements}
    F->>C: Submit transferWithAuthorization tx (F pays gas)
    C-->>F: tx confirmed
    F-->>S: SettlementResponse {txHash, status: ok}
    S-->>A: 200 OK + PAYMENT-RESPONSE header + resource body

This is the canonical x402 flow; the deferred scheme simply moves steps 6–9 after step 10 and potentially batches many of them.

2.9 Caveats and known failure modes

Two non‑trivial issues are already documented in the spec:

  • Duplicate settlement on Solana. Because Solana's RPC layer deduplicates transactions at consensus, a naive facilitator could return "success" for the same signed payload submitted twice, letting a malicious client get two resources for one payment. The x402 SVM packages mitigate this with an in‑memory SettlementCache (≈120 s TTL, roughly two blockhash lifetimes) that rejects duplicates before they ever reach the chain[^15].
  • Header size. Base64‑encoded payment objects can push HTTP headers past the default limits of popular frontends (8 KB on NGINX, 16 KB on Cloudflare). In practice this is fine for a single exact payload on USDC but becomes a concern when accepts enumerates many chains.

3. The x402 Foundation

On 23 September 2025 Coinbase and Cloudflare announced the x402 Foundation, a neutral home for the specification and reference code[^16]. The coinbase/x402 GitHub repository was transferred to x402-foundation/x402, with the former marked as a "development fork"[^17]. The foundation's stated mission is to keep x402 credibly neutral — Apache‑2.0 licensed, governed collectively, with "no branded content other than linking out to other resources where appropriate" in the canonical docs[^5].

The announcement serves two purposes. Technically, it brings Cloudflare's distribution muscle behind the spec: every Cloudflare Worker, Agent SDK deployment and MCP server is a potential 402 issuer, and Cloudflare's "pay‑per‑crawl" private beta is being re‑based on the new deferred scheme[^9]. Politically, it removes the "Coinbase proprietary" objection that had kept some enterprises away; x402 is now positioned alongside AP2 and ACP as one of the three reference agentic‑payment protocols (see Orium's comparison and discussion in 01-introduction-and-taxonomy.md).

Initial foundation contributors publicly identified in primary documentation are Coinbase and Cloudflare. Broader membership claims from third‑party blog coverage should be treated as unverified unless they appear on x402.org/ecosystem.

4. ERC‑8004 — "Trustless Agents"

4.1 What it is

ERC‑8004, titled Trustless Agents, is an Ethereum Improvement Proposal created on 13 August 2025 and authored by Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google) and Erik Reppel (Coinbase). It is currently at Draft status on the Standards Track[^18]. Its abstract is explicit about scope: "use blockchains to discover, choose, and interact with agents across organizational boundaries without pre‑existing trust, thus enabling open‑ended agent economies."[^18]

Importantly, ERC‑8004 is orthogonal to payments. The text says so directly: "Payments are orthogonal to this protocol and not covered here. However, examples are provided showing how x402 payments can enrich feedback signals."[^18] ERC‑8004 is the trust layer; x402 is the money layer; A2A and MCP are the capability layers above.

4.2 The three registries

ERC‑8004 defines three lightweight on‑chain registries, each of which can be deployed as a per‑chain singleton on L1 or any L2[^18]:

(a) Identity Registry. An ERC‑721 contract with the URIStorage extension. Each agent is an NFT whose tokenId is its agentId and whose tokenURI is an agentURI resolving to an agent registration file (JSON, ipfs/https/data URI). The global identifier is {namespace}:{chainId}:{identityRegistry} — e.g. eip155:1:0x742… — which is a CAIP‑style chain‑agnostic handle. Because it is just an ERC‑721, every existing NFT wallet can display, transfer or delegate agents. ENS is explicitly supported: an agentURI can resolve via an ENS name, giving human‑friendly agent identifiers like myagent.eth that point at signed capability documents[^18]. ERC‑1271 is listed as a dependency, which means the "owner" of an agent can itself be a smart contract (a DAO, a multi‑sig, a session key contract), not only an EOA.

(b) Reputation Registry. A standard interface for posting and fetching feedback signals about past interactions with an agent. The spec is deliberately minimal: it defines the hook, not the aggregation algorithm. Expect "on‑chain building blocks for composability + off‑chain scoring services for sophistication" to be the emerging pattern, analogous to how token lists work today. The relationship to x402 is explicit in the spec's own examples: an x402 settlement receipt can be posted as a reputation signal, so that pay‑on‑delivery interactions naturally accrue verifiable trust history[^18].

(c) Validation Registry. Generic hooks for independent validators to check an agent's work. The spec names four pluggable validation modes: economic (stakers re‑running the job), cryptographic (zkML proofs), attested (TEE oracles like Intel SGX / AWS Nitro), and social (trusted human judges). This lets a developer choose validation strength proportional to value at risk — from "pizza order, trust reputation alone" to "medical diagnosis, require zkML attestation" — without changing the wire protocol[^18].

4.3 Where it fits in the stack

The Ethereum Foundation's dAI team has publicly positioned ERC‑8004 as the on‑chain complement to MCP and A2A: MCP lists capabilities, A2A runs the conversation, and ERC‑8004 provides the portable identity and trust signals that let one agent decide whether to trust another one it has never met[^19]. The EIP's dependency list (EIP‑155, EIP‑712, EIP‑721, EIP‑1271) is deliberately conservative — nothing bleeding‑edge — which matters because it means the registries could, in principle, be deployed on any EVM chain today without protocol upgrades.

At the April 2026 snapshot, ERC‑8004 is still a Draft. The Ethereum Magicians discussion thread (ethereum-magicians.org/t/erc-8004-trustless-agents/25098) is the authoritative place for process updates[^18]. Readers should not cite it as a finalised standard.

5. Crossmint — the vertically integrated agent wallet

Crossmint's Agentic Payments product line packages most of the crypto‑stack primitives that individual developers would otherwise have to assemble themselves. Its own product page lists four components[^20]:

5.1 Agent wallets. Non‑custodial stablecoin wallets with programmatic guardrails: spending limits, merchant allow‑lists, and human‑approval thresholds. The wallets are designed to be delegated to an agent process rather than held by a human end‑user, so the guardrails are explicitly framed as "what the agent can do on its own" versus "what must route back for human sign‑off."

5.2 Virtual card issuance. Crossmint can issue virtual card numbers derived from a connected funding card so that an agent can pay at any merchant that accepts the relevant card network. The product page states the cards are issued "via Visa Intelligent [Commerce] Platform", i.e. on top of Visa's agent‑specific programme[^20]. This is the bridge between the crypto‑native wallet and the card acceptance network covered in 06-card-networks.md.

5.3 MoneyGram payouts and stablecoin onramps. Crossmint partnered with MoneyGram to enable stablecoin‑to‑cash payouts; public reporting (Crypto Briefing, following Circle Ventures' investment) cites coverage across "50 million people in 200 countries" via the MoneyGram network, and stablecoin onramps in "150+ countries" appear on Crossmint's own site[^21][^20]. These figures are vendor‑reported; the underlying partnership is verified, the reach claims are marketing.

5.4 Circle Ventures / USDC integration. Circle Ventures (Circle's investment arm) has invested in Crossmint, explicitly positioning the company as backend infrastructure for stablecoin‑based agentic finance[^21]. Crossmint also appears on Mastercard's Agent Pay partner list (see 06-card-networks.md), making it one of the few firms that sits on both the Visa and Mastercard agent rails simultaneously[^22].

Crossmint's public materials also indicate x402 acceptance support and integration with Google's agent stack, which aligns it with the AP2 side of the house as well[^20]. In practice Crossmint is best understood as a platform that hides the choice of protocol beneath a single API — a pattern we will see repeated with Stripe, PayPal and others.

6. Catena Labs and the Agent Commerce Kit (ACK)

6.1 The thesis. Catena Labs emerged from stealth on 20 May 2025, announcing an $18M seed round led by a16z crypto with participation from Breyer Capital, Circle Ventures, Coinbase Ventures, Pillar VC and angels including Balaji Srinivasan, Tom Brady, Bradley Horowitz, Hamel Husain and Sam Palmisano[^23]. The company is led by Sean Neville, previously a co‑founder of Circle. Its stated ambition is "the first AI‑native financial institution" — a regulated entity rather than purely an open protocol — built around the observation that "today's financial institutions are fundamentally unprepared for the demands of AI‑driven commerce"[^23].

The regulatory path has been signalled publicly but not completed: Catena talks about a "regulated entity designed from the ground up" and "pioneering AI‑specific risk management and compliance" but, as of April 2026, has not published specific charter or licence details. Treat statements about Catena becoming "the bank for agents" as directional rather than chartered[^23].

6.2 Agent Commerce Kit (ACK). Alongside the funding, Catena published ACK, an open‑source collection of patterns, components and emerging protocols for agent identity and payments. The kit is MIT‑licensed at github.com/agentcommercekit/ack, documented at agentcommercekit.com, and published as an agentcommercekit npm package[^24]. Its two sub‑protocols are:

  • ACK‑ID — decentralised identifiers (W3C DIDs) and W3C Verifiable Credentials for agents, structured so that an agent can cryptographically prove who it is and on whose behalf it acts, with integrated human‑oversight hooks.
  • ACK‑Pay — payment flows and cryptographically verifiable receipts between agents, humans and businesses, including HTTP 402‑style gating and stablecoin settlement.

ACK sits one layer above x402 in the stack: x402 is the wire protocol for a single payment; ACK‑Pay is an opinionated application of that protocol with richer identity, receipt and oversight semantics. Catena's own framing is that it "uses" ACK internally as building blocks, so expect a stable core plus a continually evolving surface as Catena's regulated product matures[^23].

The economic argument underpinning ACK is that the combination of AI‑native money (regulated stablecoins), programmable authorisation (mandates, guardrails) and verifiable identity closes a gap that legacy rails cannot bridge at micropayment scale. Whether Catena itself ends up as a chartered FI or as a software vendor to chartered FIs is still an open question.

7. Skyfire — payments plus Know‑Your‑Agent (KYA)

7.1 Company. Skyfire was founded in 2023 by Amir Sarhangi (previously founder of Jibe, acquired by Google; the Jibe team helped ship RCS across Android) and Craig DeWitt (formerly Ripple)[^25]. The company launched publicly on 21 August 2024 with an <span class="katex-error" title="ParseError: KaTeX parse error: Unexpected character: '&#x27; at position 163: … a cumulative ≈\̲" style="color:#cc0000">8.5M seed (TechCrunch), backed by Neuberger Berman, Inception Capital and Arrington Capital[^25]; follow‑on reporting and the source brief indicate a cumulative ≈</span>9.5M seed posture by late 2024 including Coinbase Ventures and a16z CSX participation.

7.2 Architecture. Skyfire operates on Base, with USDC as the underlying settlement asset. It assigns each agent a digital wallet identified by a unique KYA (Know‑Your‑Agent) credential; businesses deposit dollars that Skyfire converts to USDC under the hood, and spending limits (per transaction and per period) are enforced before the agent can transact. Skyfire's reported take rate is 2–3 % per transaction, with verification services flagged by management as a future additional revenue line[^25].

7.3 KYA. Know‑Your‑Agent is positioned as the agent analogue of KYC/KYB: a verified identity tuple (who the agent is, who it acts for, what scope it is authorised for) that a counterparty server can verify before transacting. It is a marketing name, not yet a standard, but the functional intent aligns with ERC‑8004's Identity Registry and with Nekuda's Agentic Mandates below. Public Skyfire documentation positions KYA as a prerequisite for "agent account creation" flows — i.e. an agent can autonomously register for a service when it can present a verifiable identity and payment capability together.

7.4 Use cases. Two early production deployments identified in primary press[^25]:

  • Denso (automotive parts) uses Skyfire agents to source materials autonomously, replacing a previous flow in which humans had to execute the end‑of‑month wire payment.
  • Payman uses Skyfire to let its AI agents pay human contractors for tasks — effectively an AI‑hires‑humans analogue of Fiverr, with Skyfire settling to the humans in USDC.

Skyfire is deliberately B2B‑first. The founders' framing — "AI agents can't do anything if they can't make payments; it's just a glorified search"[^25] — captures the pitch: without a payment rail, "agent" is marketing.

8. Nekuda — agent wallets and agentic mandates

Nekuda raised a $5M seed in May 2025, led by Madrona Ventures with participation from Amex Ventures, Visa Ventures and individual investors including Paul Klein (Browserbase) and Shyamal Anadkat (OpenAI)[^26]. Notably, both Visa and Amex are on the cap table — a signal that the firm is positioned as an agent‑commerce enabler across card networks rather than a pure crypto play.

The Nekuda SDK is structured around two primitives[^26]:

  • Agent Wallet — a container into which a user can securely delegate payment credentials (card, stablecoin, bank) for a specific agent, with the credentials surfaced to the agent at checkout time without the agent itself ever seeing raw PANs.
  • Agentic Mandates — a signed, rich authorisation message that encodes what an agent is allowed to buy, under which conditions, with which spending limits or approval rules. The mandate is designed to be passed through the payment stack so that downstream participants can trust it. This is structurally similar to AP2's Intent Mandate + Cart Mandate pattern (see 03-protocol-deep-dive-ap2.md), though Nekuda and AP2 have not (as of April 2026) published a formal interoperability mapping.

Nekuda's public partnership with Visa is the more consequential of the two Ventures' involvement: the company has stated that it intends to "integrate its AI payment stack to Visa Intelligent Commerce infrastructure"[^26]. In practice this means an agent that holds a Nekuda‑managed wallet can present a mandate that a Visa acquirer will accept as high‑quality authorisation — improving authorisation rates that today suffer because agent‑initiated transactions look a lot like card testing. This is an agent‑commerce pattern that uses the card rail for settlement but a crypto‑adjacent credential model for authorisation.

9. MCP‑based payment servers

Anthropic's Model Context Protocol (MCP), released in November 2024, has quickly become the default way to expose tools to an LLM agent. Several payment providers have shipped MCP servers, making "add a payment tool" a two‑line configuration for anyone using a compatible client (Claude Desktop, Cursor, Cloudflare Agents, OpenAI's Agent SDK, etc.).

9.1 PayPal MCP server. Announced at PayPal Dev Days on 29 April 2025, the PayPal Agent Toolkit exposes orders, invoices, disputes, catalog, shipment tracking, subscriptions and reporting as MCP tools, with first‑class support in OpenAI's Agent SDK, Vercel AI SDK and LangChain[^27]. It is bridged into the card world by PayPal's existing rails. See 07-wallets-platforms.md.

9.2 Stripe MCP / Agent Toolkit. Stripe's Agent Toolkit similarly exposes charges, customers, subscriptions and (via Stripe Issuing) virtual cards for agents; Stripe's own blog lists integrations with Anthropic, OpenAI, LangChain and Vercel SDK[^28]. Stripe's Issuing‑for‑agents product effectively makes Stripe an issuer of agent cards, which is discussed in detail in 07-wallets-platforms.md.

9.3 Cloudflare MCP + x402. Cloudflare's MCP support lets developers gate an MCP tool with x402 out of the box. This is the first production pattern combining a capability protocol (MCP) and a payment protocol (x402) at the middleware layer, with no platform sitting in between[^14].

9.4 Specialised payment MCPs. A long tail of smaller firms — Halliday (DeFi‑native agent infrastructure), Payman AI (agent‑pays‑humans work platform, a Skyfire customer), Lobstercash (listed as a Mastercard Agent Pay partner[^22]), and others — have published MCP servers tying their own balance‑sheet products to agent runtimes. Treat specific capabilities as vendor‑dependent; verify on the vendor's own docs before citing.

The important structural point is that MCP has made payment tools a commodity. An LLM agent does not need to know whether it is paying via x402 on Base, via PayPal's create_order API or via a Stripe Issuing card — each is "just another MCP tool", and the agent can choose among them at call‑time. Whether that is good (optionality) or bad (no shared semantics, invisible fee differences) is a design question protocols like AP2, ACP and ACK are each trying to answer.

10. The A2A commerce vision

Strung together, the pieces above describe a plausible architecture for agent‑to‑agent (A2A) commerce:

  1. Agents are discoverable and trustable via ERC‑8004 registries (identity + reputation + validation), optionally with W3C DIDs/VCs per ACK‑ID.
  2. Agents authenticate to each other over A2A (Google's agent‑to‑agent protocol) and expose capabilities via MCP.
  3. When a capability is paywalled, the server returns HTTP 402 with an x402 payment requirement.
  4. The client agent signs an EIP‑3009 / Permit2 authorisation and submits it via the server (which may use a facilitator). Settlement occurs in stablecoins on Base, Solana, Polygon or Avalanche.
  5. The settlement receipt is written into the Reputation Registry, continuously improving future matching.
  6. For high‑value transactions, a Validation Registry hook runs zkML, TEE or staker re‑execution before funds are released.

Nothing in this chain requires any of the following: a bank account, a card, a human clicking "pay", or a counterparty the agent has transacted with before. That is what "DeFi‑native agents" means in practice — not that every agent holds yield‑farming positions, but that every agent can transact with every other agent across organisational boundaries without pre‑existing trust or KYC onboarding.

The machine economy implication, often oversold, is more mundane than "robots replace capitalism": it is that pricing surfaces currently hidden because human checkout is too expensive (per‑API‑call, per‑token, per‑CDN‑hit) become visible and competed on. The honest version of the A2A‑commerce story is "billing becomes a first‑class HTTP concern".

11. Tradeoffs

No single rail is dominant on every axis. The crypto stack's tradeoffs versus card rails are concrete and worth enumerating plainly.

11.1 Gas costs. Even on L2s, gas is non‑zero and lumpy. A 10‑cent payment on Base that requires 50k gas at 0.05 gwei is still orders of magnitude cheaper than a card payment, but facilitators must run reliable gas markets, hold working balances in ETH/SOL, and handle mempool congestion. This is solvable engineering, not a user‑facing problem for well‑operated facilitators like CDP, but it is a real operational burden.

11.2 FX volatility. USDC and USDT track the dollar, but the agent's cost basis and the seller's treasury may both be in local fiat. Every stablecoin transaction thus implicitly embeds a pair of on/off‑ramps whose FX is not always at mid‑market. For a <span class="katex-error" title="ParseError: KaTeX parse error: Unexpected character: '&#x27; at position 36: …is fine; for a \̲" style="color:#cc0000">10 API payment this is fine; for a </span>10,000 treasury transfer it is an invisible tax worth measuring.

11.3 Regulatory clarity. Stablecoin regulation has firmed up meaningfully: MiCA in the EU, the GENIUS Act in the US (2025), and various national regimes impose reserve, redemption and disclosure rules on issuers. But the regulation of agent‑owned wallets — who is the "customer" in KYC/AML terms, who is liable for a fraudulent transfer, how is a mandate enforceable — is much less clear. See 10-regulation-and-compliance.md for detail.

11.4 UX for end consumers. The crypto stack is optimised for agents and for developers. For a grandparent whose Gmail agent is trying to book flights, "sign this EIP‑3009 message for 0.01 USDC on Base" is user‑hostile. The compromise emerging in the market is the Crossmint / Stripe Issuing / Nekuda pattern: hide the crypto stack behind a card or an app the consumer already uses, while still reaping the programmability benefits on the back end.

11.5 Dispute and reversibility. Public‑chain settlement is effectively final. Card networks' chargeback machinery — a costly but socially important backstop against fraud — does not exist in USDC on Base. Cloudflare's deferred scheme and issuer‑fronted virtual cards are two different attempts to reintroduce reversibility without giving up programmability.

11.6 Throughput and determinism. Base and Solana can clear thousands of transactions per second at sub‑second latency, which is more than adequate for agentic micropayments. But chain reorgs, facilitator outages, and RPC failures can cause transient reversals. Production x402 deployments need to code defensively around these events — the SettlementCache fix for Solana duplicate settlement is one early example[^15].

12. The fragmentation problem

The single clearest theme across the past 18 months is that the industry has produced an abundance of agentic‑payments protocols: AP2, ACP, x402, Visa's Trusted Agent Protocol, Mastercard's Agent Pay, ACK, Nekuda's Agentic Mandates, Skyfire's KYA, ERC‑8004's registries, UCP, MCP payment servers. Each addresses a genuine gap; taken together they do not yet compose.

Several interoperability efforts are visible:

  • x402 as a common settlement primitive. AP2, ACP and ACK all describe stablecoin settlement paths that could, in principle, delegate to x402 at the transport layer. Crossmint already advertises x402 acceptance on the same wallets used for card rails[^20].
  • ERC‑8004 as a common identity primitive. The spec's dependency on ERC‑721 and ERC‑1271, and its explicit compatibility with ENS, is a bet that the identity layer belongs on a public chain rather than inside any one vendor's registry. ACK‑ID's DID/VC model and ERC‑8004's Identity Registry are not in direct conflict — a DID can resolve via an agent's ERC‑8004 agentURI — but the mappings are not yet standardised.
  • The x402 Foundation's "rail‑agnostic" stance. Cloudflare's push for a deferred scheme and explicit willingness to accommodate fiat rails within x402 is an attempt to make the protocol the HTTP verb of payment, with the currency chosen at runtime.
  • Card‑network convergence. Visa Intelligent Commerce and Mastercard Agent Pay are deliberately courting the crypto stack (Coinbase is a named Visa TAP partner; Crossmint and Skyfire issue against Visa; Stripe/PayPal/Nekuda sit on both sides). Within a few years the agent rail at the card level and the agent rail at the chain level are likely to be back‑end‑swappable, with the choice made on cost and settlement properties rather than theology. See 06-card-networks.md.

Fragmentation is not (yet) a crisis — the space is too early — but it is worth being explicit about who wins if it persists. Today it is the aggregators: Crossmint, Stripe, PayPal, Cloudflare, Skyfire. They absorb heterogeneity and expose a single surface to developers. The risk for users is that "agent payment" becomes another vendor‑locked integration; the hope of ERC‑8004, ACK, x402 and the rest is that at least the identity and payment primitives remain open even if the user‑facing products do not.

The honest net assessment as of April 2026 is that the crypto stack has solved the machine‑payment primitive (x402 + EIP‑3009 + USDC on Base/Solana works, at scale, today), and is prototyping the trust primitive (ERC‑8004, ACK‑ID, KYA), while the consumer UX layer is still largely delegated to the card networks. Whether the long‑term equilibrium is "card rails with crypto settlement underneath" or "crypto rails with card‑style UX on top" is not yet decided — and most of the firms in this section are deliberately hedged across both.

Sources

[^1]: EIP‑3009, "Transfer With Authorization." Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-3009. Uniswap Permit2 reference: https://github.com/Uniswap/permit2. [^2]: Coinbase / x402, "Why Use x402?" https://docs.x402.org/. [^3]: IETF RFC 7231 §6.5.2, "402 Payment Required." https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.2. [^4]: x402 announcement (Coinbase, 6 May 2025), aggregated in source brief §A.7. Protocol docs: https://docs.x402.org/. [^5]: x402 Foundation, homepage. https://www.x402.org/ (accessed 21 April 2026). Transaction/volume figures are self‑reported and displayed on the homepage dashboard. [^6]: x402 docs, "HTTP 402." https://docs.x402.org/core-concepts/http-402. [^7]: x402 docs, "Facilitator." https://docs.x402.org/core-concepts/facilitator. [^8]: x402 specs directory, specs/ in the foundation repo. https://github.com/x402-foundation/x402. The EIP‑3009 transferWithAuthorization dependency is standard across EVM implementations of the exact scheme. [^9]: Cloudflare blog, "Introducing the x402 Foundation and a new deferred payment scheme," 23 September 2025. https://blog.cloudflare.com/x402/. [^10]: x402 Foundation GitHub, package list including @x402/evm, @x402/svm, @x402/stellar. https://github.com/x402-foundation/x402. Ecosystem registry: https://www.x402.org/ecosystem. [^11]: x402 Foundation, "Zero protocol fees" design principle. https://www.x402.org/ and https://docs.x402.org/. [^12]: Coinbase Developer Platform, "x402 welcome" documentation. https://docs.cdp.coinbase.com/x402/welcome. Specific free‑transaction allowances on Base are subject to change; developers should confirm current pricing with CDP directly. The overall claim of a CDP‑sponsored free tier on Base is referenced in the source brief §A.7. [^13]: x402 Foundation README, installation sections for TypeScript, Python and Go. https://github.com/x402-foundation/x402. [^14]: Cloudflare Developers, "Agents SDK x402 integration." https://developers.cloudflare.com/agents/x402/ and MCP documentation at https://developers.cloudflare.com/agents/model-context-protocol/. [^15]: x402 docs, "Duplicate Settlement (Solana)" subsection of the Facilitator page. https://docs.x402.org/core-concepts/facilitator. [^16]: Cloudflare press/blog, 23 September 2025. https://blog.cloudflare.com/x402/. [^17]: coinbase/x402 repository README: "We've moved the x402 repo under the x402 Foundation repo … coinbase/x402 is now a development fork." https://github.com/coinbase/x402. [^18]: ERC‑8004, "Trustless Agents." Authors: Marco De Rossi, Davide Crapis, Jordan Ellis, Erik Reppel. Status: Draft, created 13 August 2025. https://eips.ethereum.org/EIPS/eip-8004. Discussion: https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098. [^19]: Ethereum Foundation dAI team, "Intro to ERC‑8004." https://ai.ethereum.foundation/blog/intro-erc-8004. [^20]: Crossmint, "Agentic Payments" product page. https://www.crossmint.com/solutions/agentic-payments. [^21]: Crypto Briefing, "Circle Ventures invests in Crossmint." https://cryptobriefing.com/circle-ventures-investment-crossmint-stablecoin/. [^22]: Mastercard Agent Pay partner list (see 06-card-networks.md); original source listed in master brief §A.4. Partner roster includes Crossmint and Lobstercash. [^23]: Catena Labs, "Building the First AI‑Native Financial Institution," 20 May 2025. https://www.catenalabs.com/blog/announcing-catena-labs/. Press mirror: https://www.businesswire.com/news/home/20250520361792/en/. [^24]: Agent Commerce Kit documentation, https://www.agentcommercekit.com and repository https://github.com/agentcommercekit/ack. MIT‑licensed, ACK‑ID and ACK‑Pay sub‑protocols described in kit documentation. [^25]: Maxwell Zeff, "Skyfire lets AI agents spend your money," TechCrunch, 21 August 2024. https://techcrunch.com/2024/08/21/skyfire-lets-ai-agents-spend-your-money/. Skyfire product site: https://skyfire.xyz/. [^26]: Crowdfund Insider, "Fintech Startup Nekuda Secures Funding Led by Madrona Ventures," May 2025. https://www.crowdfundinsider.com/2025/05/239660-fintech-startup-nekuda-secures-funding-led-by-madrona-ventures-to-enable-agentic-payments/. Product page: https://www.nekuda.ai/. [^27]: PayPal Newsroom, "PayPal Brings Together Developers, AI Leaders to Power Agentic Commerce at Dev Days," 29 April 2025. https://newsroom.paypal-corp.com/2025-04-29-PayPal-Brings-Together-Developers,-AI-Leaders-to-Power-Agentic-Commerce-at-Dev-Days. Agent Toolkit docs: https://paypal.gitbook.com/agent-toolkit-and-mcp-server/agent-toolkit/quickstart. [^28]: Stripe Agent Toolkit and Issuing for agents. See Stripe newsroom (https://stripe.com/newsroom/news/stripe-and-openai) and Stripe's agentic commerce docs at https://docs.stripe.com/agentic-commerce/protocol.