x402 is an open payment-protocol specification that revives the long-dormant HTTP 402 Payment Required status code as a machine-readable, rail-agnostic payment-request mechanism. An API that wants to be paid per call returns a structured 402, the client (typically an AI agent) interprets the request, signs and broadcasts a payment on the rail named in the request, and retries with proof. Coinbase has been the most prominent driver since the open-sourcing of the spec in mid-2025, with the reference implementation tied to USDC, but the design is rail-agnostic in principle: any settlement asset whose receipts can be presented as machine-verifiable proof can sit underneath. For a tokenisation operator, x402 is the cleanest existing primitive for "agent pays for something" without bespoke integration work, and the resource tracks it as the load-bearing chain-native payment standard for agentic commerce on tokenised rails (x402.org, Coinbase developer docs).
What it is
The protocol takes the otherwise-unused HTTP 402 status code and standardises a structured response body that names the accepted payment methods, the amount, the recipient address (or its equivalent on non-EVM rails), an optional expiry, and the proof format the server expects on retry. The client posts a payment on the named rail, receives a transaction hash or equivalent receipt, and resends the original request with the receipt attached as a header. The server verifies the receipt before serving the response. The whole exchange is HTTP-native, which is the load-bearing design choice: any HTTP-speaking client can be made x402-aware without leaving the request-response model that already underpins the web.
The spec is open and the reference implementations are MIT-licensed. The Coinbase team published the initial reference middleware for Node.js, Python, and Go server frameworks alongside an SDK for client-side integration, with USDC on Base as the default settlement leg. Subsequent community implementations cover other USDC-supporting chains (Solana, Ethereum mainnet, Polygon, Arbitrum, Optimism) and have begun to wire up Lightning Network and Bitcoin layer-2 settlement as alternative rails. The protocol does not prescribe a settlement asset; it prescribes the request-response shape inside which the asset choice is named.
The agent-friendly properties are deliberate. The 402 response is fully machine-readable, which means an agent's wallet client can parse it without HTML-scraping or human-in-the-loop. The proof-of-payment retry pattern means there is no out-of-band webhook or callback that needs to traverse a corporate firewall. The micro-amount support, with USDC settlement on a low-fee L2 like Base, makes per-call pricing economically viable for the first time outside Lightning. For an API selling inference, data, or compute to autonomous agents, x402 is the integration that closes the loop.
Where it sits in the stack
x402 sits one layer above the settlement rail and one layer below the agent runtime. The settlement rail (USDC on Base in the reference case, but any asset on any chain in principle) handles the value transfer and finality. The agent runtime (the LLM-driven orchestrator, MCP server, or agent framework that decides to make the call) handles the principal-side authority and the higher-order goal. x402 is the protocol that lets the two talk to each other in a standardised, HTTP-native way without either side needing to know the internals of the other.
The architectural read for a tokenisation operator is that x402 is the payment primitive most likely to be inbound to a tokenised-rail product. A stablecoin issuer integrating x402 server-side is letting agents pay it directly. A bank's tokenised-deposit rail wiring up x402 acceptance is letting agents on its principals' behalf pay other endpoints in tokenised deposits. The integration cost is small relative to bespoke connector work because the spec is open and the reference implementations are production-grade.
The composition story is the more interesting one. x402 plus the W3C Verifiable Credential and Decentralised Identifier standards (covered in Foundations Chapter IX, Part 3) gives the full agentic-commerce loop: the agent presents a credential proving the principal's authority for the class of payment, the API accepts the credential, returns a 402 if payment is required, and the agent settles on the named rail. Identity, authority, and payment are the three composable primitives; x402 is the payment leg.
Institutional adopters and where they sit
The named institutional adopters cluster around Coinbase's existing payments orbit. Coinbase itself runs the reference x402 middleware and has integrated x402 across its developer-facing APIs as both server and client. Stripe, in its Agent Toolkit, recognises x402 as one of the supported inbound payment patterns for merchants accepting agent-initiated payments, alongside its existing card-rail integration. Anthropic published documentation on x402 integration for Claude-based agent workflows in late 2025, with a worked example of an MCP server accepting USDC payments for inference time, though the deployment is sample code rather than a production payment surface (Anthropic developer documentation, accessed April 2026). The infrastructure-startup adopters (Skyfire, Catena Labs, Halliday, the various x402-as-a-service vendors that have appeared since mid-2025) are at the early-integration stage, with most still selling integration tooling rather than production volume.
The institutional gap is the regulated-bank tokenised-deposit side. As of April 2026, no major commercial bank has publicly announced x402 acceptance on its tokenised-deposit rail. Kinexys, DBS Token Services, BNY's tokenised-deposit platform, and Citi Token Services do not yet expose x402-compatible endpoints. We read this as a timing rather than a structural issue: the integration is technically straightforward, the regulatory perimeter on tokenised deposits does not block it (covered in Foundations Chapter IX, Part 2), and the operational policy gating is internal to each bank rather than mandated externally. The bank that ships x402 acceptance first on its tokenised-deposit rail will set a meaningful reference point for how agentic flows compose with bank-issued tokenised cash.
The volume signal is small relative to traditional payment flows. Public x402-tagged volume across all named integrations was reported in single-digit USD millions through 2025 (industry coverage in late 2025), with the integration cost story rather than the volume story driving adoption to date. We track this as a leading indicator: x402 volume becoming material would be one of the clearest signals that agentic commerce on tokenised rails has moved from architectural experiment to operational pattern.
Open questions
- Whether a major tokenised-deposit rail (Kinexys, DBS Token Services, CTS, BNY) ships native x402 acceptance, and on what timeline. The first to ship sets the bank-money reference point.
- Whether the GENIUS Act regulated-stablecoin issuers (USDC under Circle's federal pathway, the various bank-issued stablecoins under the OCC perimeter) integrate x402 acceptance as a standard server-side primitive, and whether the OCC publishes any view on whether x402-routed flows trigger any specific issuer-side controls.
- How the pattern composes with MAS Project Orchid purpose-bound money structures, where the principal grants conditional authority that the chain enforces. PBM plus x402 is the architectural sketch we find most interesting on the Singapore side.
- Whether the protocol attracts any explicit regulatory commentary, particularly from BIS in its forthcoming work on programmable money or from MAS in any update to the digital-token-service-provider perimeter. Silence is the current state; explicit accommodation or explicit constraint would each move the field.