x402 is a payment protocol that turns the dormant HTTP 402 status code into a working machine-to-machine settlement layer for stablecoins. A server returns 402 with payment terms in a response header. The client signs a token transfer authorization, retries the request with a payment header, and the server delivers the resource once a facilitator confirms onchain settlement. The flow runs over standard HTTP, takes one round trip, and lets an agent pay a fraction of a cent for an API call without an account, an API key, or a monthly invoice. Coinbase open-sourced x402 in May 2025, then donated it to the x402 Foundation at the Linux Foundation on April 2, 2026. By late April 2026 the protocol had reached 69,000 active agents, 165 million transactions, and roughly $50 million in cumulative volume. This piece is the technical primer: the four-step request flow, the headers, the EIP-3009 and Permit2 signing paths, the facilitator role, the supported chains, and the production deployments running on x402 today.
​

x402 is an open HTTP payment protocol that turns the dormant 402 Payment Required status code into a working stablecoin settlement layer. A server returns 402 with payment terms, the client signs a token transfer authorization, and a facilitator confirms onchain settlement before the resource ships. The protocol runs over standard HTTP, takes one round trip, and is chain-agnostic by design.
​

x402 is an open HTTP payment protocol that uses the 402 Payment Required status code to negotiate and settle stablecoin transfers between a client and a server. The status code itself was reserved in the original HTTP/1.0 specification in 1991 but never standardized for any specific payment system; for thirty-five years it sat in the spec as a placeholder. x402 fills that placeholder with a concrete schema: a JSON envelope in the response header for what payment is required, and a signed payload in the request header for the response.
​

The protocol is permissionless and chain-agnostic by design. Any server can return 402, any client can satisfy it, and the underlying token transfer happens onchain rather than through a card network. Coinbase published the first reference implementation under Apache 2.0 with TypeScript, Python, and Go SDKs at github.com/coinbase/x402, alongside framework adapters for Express, Fastify, Next.js, and Axios. The reference repo currently records 28 releases. The official spec lives under the x402 Foundation at x402.org.
​

Governance moved to the x402 Foundation in two steps. Coinbase and Cloudflare announced the foundation on September 23, 2025. The Linux Foundation formalized it on April 2, 2026 at the MCP Dev Summit North America. The launch member list spans 22 organizations including Adyen, AWS, American Express, Base, Circle, Fiserv Merchant Solutions, Google, KakaoPay, Mastercard, Microsoft, Polygon Labs, PPRO, Shopify, Solana Foundation, Stripe, thirdweb, and Visa. The foundation owns the spec, runs working groups, and maintains the canonical reference implementations. Coinbase contributed the protocol but does not control its evolution.
​

The scale numbers point to a real workload, not a demo. Coinbase reported 69,000 active agents, 165 million transactions, and approximately $50 million in cumulative volume on x402 by late April 2026, the week it launched the Agent.market directory of x402-paywalled services. The implied average value per call sits near $0.30, calibrated for sub-cent and small-cents API metering rather than retail purchases. The transaction count alone exceeds the daily volume of most consumer-facing payment processors at the same ticket size, an early read on how dense agent traffic gets when the friction of accounts and API keys disappears.
​

Every x402 transaction follows a four-step request-response cycle: the client pings the endpoint, the server returns 402 with payment terms, the client signs a token transfer authorization, and the client retries the request with the signed payload in a header. A facilitator confirms onchain settlement, then the server returns the resource alongside an optional receipt header.
​

Every x402 transaction follows a four-step request-response cycle. The client makes a normal HTTP request. The server returns 402 with payment terms. The client constructs and signs a payment payload. The client retries the request with the signed payload in a header, and the server returns the resource after a facilitator confirms settlement. The protocol uses two named headers: PAYMENT-REQUIRED on the response side and PAYMENT-SIGNATURE on the request side, with an optional PAYMENT-RESPONSE for settlement confirmation.
​

The client issues a normal HTTP request to a paywalled resource. No special headers, no authentication, no payment information. From the client's perspective this is the same request it would make against an unauthenticated endpoint.
​

The server responds with HTTP status 402 Payment Required. The body and the PAYMENT-REQUIRED header carry a JSON envelope describing what the client needs to pay. The fields are minimal but specific: a payment scheme (the protocol uses exact for fixed-amount transfers, with experimental support for upto consumption-based pricing), a network identifier in CAIP-2 format such as eip155:8453 for Base, the asset contract address (typically the USDC contract on the named network), the recipient address, the maximum amount, an expiry timestamp, and an optional facilitator endpoint URL.
​

The CAIP-2 namespace matters because it is what makes x402 chain-agnostic. eip155:1 is Ethereum mainnet. eip155:8453 is Base. solana:mainnet is Solana. The same protocol envelope describes a payment regardless of the underlying chain, which lets clients route to whichever network has the cheapest gas and the right token. The Coinbase facilitator currently supports Base, Polygon, Arbitrum, and World as EVM networks, plus Solana for SVM. Stellar shipped a production-ready x402 facilitator (Built on Stellar / OpenZeppelin Relayer) in March 2026, joining the EVM and SVM tracks already in the CDP facilitator.
​

The client reads the PAYMENT-REQUIRED envelope and constructs a signed transfer authorization. x402 supports two signing paths depending on the token. The EIP-3009 path handles USDC and EURC, both of which implement the transferWithAuthorization entry point natively. The Permit2 path handles every other ERC-20.
​

EIP-3009 was proposed by Peter Jihoon Kim, Kevin Britz, and David Knott on September 28, 2020. The core function takes seven fields: from, to, value, validAfter, validBefore, nonce, and a signature over the EIP-712 typed-data hash. The nonce is a random 32-byte value rather than a sequential counter, which is what lets a wallet construct several authorizations in parallel without collision. Circle's USDC contract has implemented EIP-3009 since the v2 upgrade, which is why it is the smoothest path for x402 transfers; the facilitator submits the signed authorization and the recipient's balance updates without a prior approval transaction.
​

Permit2, originally shipped by Uniswap in 2022, sits in front of any ERC-20. The client signs a Permit2 message with a deadline and a token-spend allowance scoped to the Permit2 contract. The facilitator submits a single transaction to Permit2, which pulls the ERC-20 from the client's address and forwards it to the recipient. Permit2 charges one approval ever (to itself) per token; subsequent payments require only an off-chain signature.
​

Solana follows a different mechanism because it has neither ERC-20 nor EIP-712. The x402 Solana implementation uses a partial transaction signed by the client. The client constructs a Solana SPL token transfer, signs the message, and sends the partial transaction to the facilitator. The facilitator co-signs as fee payer and submits to a validator. Functionally the result is the same: the client never holds SOL for gas, and the recipient receives SPL USDC.
​

The client makes the same request again. This time it includes the signed payload in the PAYMENT-SIGNATURE header, encoded as base64. The server has two options for verification. It can pass the signed payload to a facilitator over a separate API call, in which case the facilitator validates the signature, simulates the onchain call, broadcasts the transaction, waits for confirmation, and returns success. Or the server can run the verification itself by holding its own RPC keys and calling the token contract directly. Most production deployments use a facilitator because the operational footprint of running RPC infrastructure across four chains is non-trivial.
​

Once settlement confirms, the server returns 200 with the resource and an optional PAYMENT-RESPONSE header carrying the transaction hash and any settlement metadata. The client now has both the data it requested and a verifiable receipt of payment. Total round-trip latency is dominated by the chain confirmation rather than the HTTP layer; on Base, where blocks land every two seconds, an end-to-end x402 call typically completes inside three or four seconds. Allium's x402 explainer documents the same flow and notes that facilitators handle gas, retries, and chain routing on behalf of both ends.
​

The whole exchange composes with anything that already speaks HTTP. An agent calling a paywalled REST endpoint adds one header and handles one extra status code. A model gateway proxies x402 calls without inspecting them. The Cloudflare Agents SDK ships native middleware that intercepts 402 responses, fetches the appropriate signature from a configured wallet, and retries automatically, which means in many client codepaths the protocol is invisible above a single SDK call.
​

The x402 stack splits across three operational layers: a facilitator that handles signature verification and onchain submission, a foundation that owns the protocol specification, and a chain layer that holds the stablecoin balances. Each layer is swappable, and merchants can run their own facilitators or bypass them entirely with self-managed RPC infrastructure.
​

x402 is a thin protocol that delegates most heavy lifting to three external pieces: the facilitator that handles chain submission, the foundation that owns the spec, and the chain itself that holds the stablecoin balances. Each layer has a specific shape worth understanding before integrating.
​

The facilitator is the operational layer. It accepts a signed payload, verifies the signature, simulates the token transfer, broadcasts the transaction, and reports back to the server. Coinbase runs the most-used implementation, the CDP Facilitator, which is free for the first 1,000 transactions per month and charges $0.001 per transaction beyond that according to the CDP docs. Cloudflare ships a facilitator inside its Agents SDK with a deferred-payment scheme that batches sub-cent payments and settles on a separate cadence, useful for very high-frequency calls. Anyone can run a facilitator. The protocol does not require a specific operator, and merchants with their own RPC infrastructure can bypass facilitators entirely.
​

The x402 Foundation is the standards layer. Sitting under the Linux Foundation, it owns the protocol specification, runs working groups, and maintains the reference implementations. The 22-organization launch list spans payment networks (Visa, Mastercard, American Express, PayPal-affiliated PPRO, Adyen, Stripe, Fiserv), cloud and infra (AWS, Cloudflare, Microsoft, Google, thirdweb), stablecoin issuers and chains (Circle, Base, Polygon Labs, Solana Foundation), and shopping surfaces (Shopify). The breadth matters: x402 is not a stablecoin-only protocol or a Coinbase-only protocol. It is positioned to settle in fiat eventually through the card-network members, even though every production deployment in April 2026 uses stablecoins.
​

The chain layer is where the stablecoin actually moves. Base is the default in most x402 docs because Coinbase is the issuer of the chain and the protocol's incubator. Polygon, Arbitrum, and World cover the rest of the EVM footprint inside the CDP facilitator. Solana lives in its own track with SPL USDC and the partial-transaction signing path described above. Stellar has its own production facilitator (run by OpenZeppelin's Relayer service) that went live in March 2026. Stablecoins that travel x402 today are USDC and EURC on EVM (via EIP-3009), and SPL USDC on Solana. CoinGecko's x402 endpoint notes that Base and Solana are the two settlement networks accepted at the time of the integration.
​

Each chain has its own gas economics, and that is where the protocol bumps into reality. Base settles in roughly two-second blocks for fractions of a cent in gas. Solana settles in about half a second for similar fees. Arbitrum and Polygon are slower than Base but faster than Ethereum mainnet. Ethereum L1 is technically supported but functionally too expensive for the sub-dollar payments x402 is designed for. Routing decisions inside agent stacks usually default to Base for EVM and Solana for high-throughput cases, with the rest reserved for specific chain-local services.
​

Five named x402 deployments were running in production by April 2026: Coinbase Agent.market, Stripe Machine Payments, CoinGecko paid endpoints, Circle Wallets reference workflow, and the Cloudflare Agents SDK. Together they account for the bulk of the 165 million transactions and roughly $50 million in cumulative protocol volume reported at the Foundation launch.
​

x402 left the demo phase by the end of Q1 2026. Five named deployments are running in production today and are worth examining as a sanity check on the protocol's actual usage.
​

Coinbase Agent.market. Coinbase launched Agent.market in April 2026 as a directory of x402-paywalled services aimed at autonomous agents. The marketplace organizes endpoints into seven categories — reasoning, data, media, search, social, infrastructure, and trading. Each listing carries pricing, an example call, and a payment endpoint. The 165 million transactions and roughly $50 million in cumulative volume cited at launch are the protocol-wide totals across all x402 services as of mid-April 2026, not the marketplace alone, but Agent.market consolidates discovery in a way that pushed adoption sharply that month.
​

Stripe Machine Payments. Stripe shipped x402 support on February 10, 2026 in a preview product called Machine Payments, announced by product manager Jeff Weinstein. The launch supports USDC on Base. Stripe also released an open-source CLI named purl, plus Python and Node sample code for both the client and server sides. Stripe positions Machine Payments as a developer-facing extension of its broader Agentic Commerce Suite, which targets agent-initiated card payments and stablecoin payments inside the same Stripe account. The Block's coverage of the launch confirms the Feb 10 date and the USDC-on-Base launch pair.
​

CoinGecko x402 endpoints. CoinGecko activated x402 across a set of high-leverage market-data endpoints (token prices, DEX liquidity, trending activity) on the same window as the Stripe launch. Pricing is a flat $0.01 USDC per request, with payment accepted on Base or Solana. The integration eliminates the API-key onboarding that previously required a CoinGecko account and a paid subscription tier. An agent that needs a single price quote pays a cent and gets the data; an agent that polls heavily pays in proportion. Coinbase's launch page for the integration documents both the pricing and the supported networks.
​

Circle Wallets + USDC. Circle published a reference workflow for autonomous agents using Circle Wallets, USDC, and x402. The flow combines Circle's MPC-based developer wallets with the EIP-3009 transferWithAuthorization path. An agent provisions a Circle wallet through the API, funds it with USDC (testnet via faucet), encounters an x402 paywall, calls the Circle Signing API to produce the EIP-712 signature, and posts the result via PAYMENT-SIGNATURE. The reference example pays $0.01 USDC for wallet risk-profile data. Circle's blog frames the integration as the canonical pattern for agent payment infrastructure where the agent never holds raw private keys.
​

Cloudflare Agents SDK. Cloudflare integrated x402 into its Agents SDK and MCP servers on September 23, 2025, the same day the foundation was announced. The integration includes a deferred-payment scheme designed for sub-cent transactions where per-call settlement costs more than the call. Clients post a credential, servers record consumption, and settlement happens on a separate cadence. The Cloudflare implementation also ships an x402 Playground for developers testing the flow without onboarding a wallet first.
​

Around these five anchors sit dozens of smaller integrations. Allium offers x402-paywalled onchain data through its Allium for Agents product. StraitsX added native x402 support for XSGD and XUSD on Solana in December 2025. The reference SDKs accumulate community frameworks (FastAPI, Hono, Cloudflare Workers) outside the official adapter set. The 165 million transaction count is the number that integrates all of these.
​

x402 trades dispute rights, sub-millisecond latency, and gas-free settlement for chain-native finality and accountless payments. Transactions are non-reversible, end-to-end latency is bound by chain confirmation, and microtransactions below a cent run into gas economics that motivate deferred-payment schemes. Custody also shifts to the agent, requiring MPC wallets or session keys.
​

x402 solves a specific class of problem and creates new tradeoffs that traditional payment rails do not have. Three are worth flagging in any production-deployment evaluation.
​

The first is microtransaction economics. x402 is competitive at $0.30 per call because the gas to settle a USDC transfer on Base is well under a cent. At $0.0001 per call, the gas itself becomes a meaningful portion of the spend, which is what motivates Cloudflare's deferred payment scheme and the experimental upto consumption-metered scheme in the reference repo. Most current deployments price in single-digit cents per call (CoinGecko at $0.01, Circle's reference at $0.01), which sits in the comfort zone where standard exact mode is profitable for both ends.
​

The second is settlement finality and chargeback semantics. x402 transactions are non-reversible by design. Once the facilitator confirms onchain settlement, there is no chargeback path, no dispute window, no merchant pull-back. This is intentional — agents and APIs do not have the human-dispute infrastructure that justifies card-network reversal — but it is a sharp departure from how Stripe and Visa handle agent payments on their card-rail products. Mastercard's Agentic Tokens and OpenAI's Shared Payment Tokens both keep dispute rights in place. x402 does not. Production deployments should treat the payment as final the moment 200 returns and architect refunds at the application layer if they need them.
​

The third is custody. x402 requires the client to hold a wallet that can sign transfers. For an agent acting on behalf of a human user, that means either the user's wallet (with delegated signing), an MPC-backed agent wallet (Circle Wallets, Coinbase Smart Wallet), or a session-scoped key issued by the agent platform. Each option has its own operational profile. Bare private keys held by an autonomous process are the worst version of this; MPC-backed wallets with policy controls (per-call spend limits, per-day caps, per-merchant allowlists) are the production pattern most large integrators are settling on. The stablecoin developer tools ecosystem now includes wallet-as-a-service offerings explicitly marketed for agent payments.
​

Latency rounds out the limits. The HTTP layer adds a single round trip on top of the chain-confirmation time. On Base that means roughly three to four seconds end to end. On Solana, closer to one to two. Compared with a card-network call (typically 200–800 ms for Visa or Mastercard authorization), x402 is one to two orders of magnitude slower per call. For sub-second agent-to-agent calls inside a single hot loop, that latency floor matters. Many deployments mitigate it by using deferred payment for high-frequency paths and reserving exact-mode x402 for the discrete, paid actions where settlement confirmation is the goal.
​

x402 sits at the machine-to-machine API payment layer and does not compete with adjacent agentic protocols. ACP and UCP handle agent-to-merchant retail checkout, AP2 and TAP handle authorization attestation, and MCP handles tool discovery. Most production agent stacks use x402 alongside these protocols rather than choosing between them.
​

x402 is one piece of the broader agentic commerce stack. It does not compete head-on with the other agent-payment protocols; it sits at a different layer. A short comparison clarifies where x402 stops and other protocols begin.
​

OpenAI's Agentic Commerce Protocol (ACP) and Google's Universal Commerce Protocol (UCP) handle agent-to-merchant checkout for retail purchases. They issue scoped ephemeral tokens (Stripe Shared Payment Tokens for ACP) that route through traditional card networks. ACP and UCP and x402 are complementary: a shopping agent might use ACP to buy a sweater on Etsy and x402 to pay for the price-comparison API it consulted on the way.
​

Google's Agent Payments Protocol (AP2) and Visa's Trusted Agent Protocol (TAP, launched October 14, 2025) sit on the authorization side. AP2 attaches a cryptographic mandate to a payment confirming a user delegated the action; TAP signs the agent's identity into HTTP request headers. Both are designed to make the merchant comfortable that the agent is real and the user authorized the call. x402 does not solve agent-identity attestation. It solves payment movement, given that authorization has already happened upstream.
​

Anthropic's Model Context Protocol (MCP), open-sourced in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, is the data layer below all of these. MCP servers expose tools (search a catalog, read a database, call an API). x402 is the natural payment companion: an MCP server can return 402 to monetize its tools without changing the JSON-RPC schema, and the Cloudflare integration ships exactly that pattern. The two protocols compose in a way that doesn't require either side to know about the other.
​

For most agent-payment systems in production, the protocol stack is layered: MCP for tool discovery, x402 for machine-to-machine API payments, ACP or UCP for retail checkout, AP2 or TAP for the authorization signature. Stablecoin agent payments as a category currently route through x402 for the vast majority of sub-dollar settlements, and through MPP or ACP for higher-value flows.
​

Sources and methodology. Protocol specifications verified against the x402 reference repository and Coinbase x402 documentation. Active-agent and transaction figures from Cryptonews' April 2026 reporting. Stablecoin supplies pulled from DeFiLlama on April 30, 2026. Figures refresh quarterly.
​

x402 specifies the protocol; it does not specify which chain the dollars sit on. When an agent paying USDC on Base needs to pay a recipient whose treasury lives on Solana, Arbitrum, or Tron, x402 gets the agent to the payment endpoint but does not bridge the funds. Eco operates as the cross-chain stablecoin orchestration layer that fills that gap, abstracting routing, solver selection, and finality across 15 chains. An agent integrated against Eco can pay an x402 endpoint anywhere without holding a separate wallet or liquidity pool per chain; the orchestration network handles where the dollars settle. Agentic payments systems running x402 at scale typically pair the protocol with this orchestration layer because settlement chain selection becomes its own engineering surface once the agent footprint moves past one network. Cross-chain messaging is the third leg of the same stack, handling the under-the-hood transport that lets routes settle across chains in seconds rather than minutes.
​