What Is x402? The Payment Protocol Built for AI Agents

• HTTP 402, revived: x402 uses the long-reserved HTTP status code 402 Payment Required to let a server tell a client exactly what a resource costs and how to pay for it, all inside a normal HTTP request/response cycle.

• Built for machines, not humans: An AI agent cannot fill out a checkout form. x402 replaces that with a signed, gasless authorization the agent's wallet produces automatically, so payment adds one extra round trip instead of a human approval step.

• Stablecoins do the settling: Payments move as USDC or EURC, mostly on Base and Solana, using EIP-3009 signed authorizations on EVM chains and partially-signed transactions on Solana.

• Facilitators never hold funds: A facilitator server checks and submits payments on the payer's behalf, but it can only broadcast what the client already signed. It cannot change the amount or the destination.

• Governance moved to the Linux Foundation: Coinbase built x402 alone in 2025, then handed stewardship to a new x402 Foundation under the Linux Foundation in April 2026, with 22 members including Visa, Mastercard, Google, AWS, and Circle.

• Adoption is real but overstated: Coinbase cites over 165 million transactions and $50 million in volume, but independent analysts found that a large majority of that activity, in some periods over 90%, was wash trading rather than genuine demand.

• It sits below MCP, not instead of it: The Model Context Protocol handles how an agent discovers and calls a tool. x402 handles what happens when that tool call returns a bill.

• Security research has found real gaps: Two academic papers published in May 2026 demonstrated concrete attacks, including duplicate payment grants and cache leakage of paid content, against production-style x402 deployments.

x402 is an open, HTTP-native payment protocol that lets a client, most often an AI agent, pay for a web resource in a single request/response cycle using stablecoins. It was created by the Coinbase Developer Platform team and publicly launched with a whitepaper on May 6, 2025.

The name comes directly from the HTTP status code it uses: 402 Payment Required. That code has existed in the HTTP specification since the 1990s but was never standardized for actual use. It sat in the spec, reserved, for over two decades. x402 is the first protocol to give it a real, working job.

In plain terms: a server can respond to a request with "this costs $0.001, here is how to pay," and the client can pay and retry, all without a human clicking anything. Erik Reppel, the protocol's principal architect at Coinbase, framed the ambition directly at launch: "Just like HTTPS secured the web, x402 could define the next era of the internet."

x402 is not an official internet standard yet. As of mid-2026, it remains an application-layer convention rather than an IETF or W3C standard, though the newly formed x402 Foundation has stated an aspiration to pursue that path.

The problem x402 solves is simple to state: software cannot fill out a payment form. An AI agent that needs to call a paid API, buy a dataset, or pay a fellow agent for compute has no good way to do it today. It cannot sign up for a SaaS account, enter a credit card, or negotiate a contract. Every one of those steps assumes a human is present.

Traditional payment rails were built around recurring relationships: a subscription, a stored card, an approved vendor. Agentic commerce is the opposite. An agent might call thousands of different endpoints it has never seen before, each needing a payment that is tiny (fractions of a cent) and instant. Setting up a billing relationship for each one is not realistic.

Coinbase describes x402 as the culmination of internal exploration into internet-native payments dating back to 2015, citing Balaji Srinivasan's 21.co Bitcoin micropayment work as an early inspiration. What made it practical in 2025 was cheap settlement: low-fee layer-2 chains like Base bring on-chain fees down to roughly a cent, making per-request payment economically viable for the first time.

The core loop is short. A client requests a resource, gets told the price, pays, and gets the resource, all inside what looks like two HTTP requests. 

Step by step, using the v2 semantics of the spec:

1. The client (an agent, a script, a browser) requests a resource from a server.
2. The server responds with 402 Payment Required and a machine-readable PaymentRequirements object describing exactly what it costs, in which token, on which chain.
3. The client picks one accepted payment option and builds a PaymentPayload: a cryptographically signed authorization to transfer the required amount.
4. The client resends the same request, this time with the signed payment attached in an HTTP header.
5. The server checks the payment, either locally or by calling a facilitator's /verify endpoint (roughly 100 milliseconds).
6. If valid, the server does the requested work and settles the payment on-chain, directly or via the facilitator's /settle endpoint (roughly 2 seconds on Base).
7. The server returns 200 OK with the resource, plus a receipt confirming the payment settled. 

The whole exchange, discovery of price, signing, and settlement, happens without a human approving anything mid-flow. That is the entire point: it turns payment into a protocol-level detail instead of a UX interruption.

Two data structures carry the whole transaction. PaymentRequirements is what the server sends back with its 402 response. It specifies the scheme (the payment method, most commonly exact for a fixed price), the network, the asset (usually USDC), the payTo address, a maximum timeout, and a plain-English description of the resource.

PaymentPayload is what the client sends back. For the most common EVM setup, it contains a signature and an authorization object: the sender, recipient, amount, a validity time window, and a random nonce. Nothing here requires the client to hold ETH for gas or interact with a wallet UI. It is a signed piece of data, produced instantly and offline.

A single server can advertise several accepted options at once, for example USDC on Base or USDC on Ethereum, letting the client pick whichever it already supports. This multi-option design is what lets x402 stay chain-agnostic instead of locking servers or agents into one network.

On EVM chains, the default payment method is EIP-3009, a token standard extension that supports transferWithAuthorization. This lets a user sign a message off-chain, using the standard EIP-712 typed-data signing scheme, authorizing a specific transfer without needing to submit a transaction or pay gas themselves. 

The signed authorization includes a random 32-byte nonce rather than a sequential counter, which matters for agents specifically: it lets a wallet construct many payment authorizations in parallel without worrying about ordering conflicts, which is exactly the access pattern a busy agent needs. The authorization also carries validAfter and validBefore timestamps, so a signed payment cannot be replayed outside its intended window, and the underlying token contract marks each nonce as used once it settles. 

For tokens that do not natively support EIP-3009, x402 falls back to Permit2, a more universal approval mechanism that works with any ERC-20 token. On Solana, the mechanism looks different: the client partially signs a transfer transaction, and the facilitator adds its own signature as the fee payer before submitting it. This composability, letting one protocol span very different signature schemes across EVM and Solana, is part of why the design stays chain-agnostic. This is a similar underlying goal to what account abstraction under EIP-4337 and gasless permit approvals under EIP-2612 already do elsewhere in Ethereum: move the friction of gas and signing away from the end user.

Three roles make up every transaction. 

• The client is whoever wants the resource: usually an AI agent, but it can just as easily be a script, a browser extension, or a human using a wallet. The client's only job is to hold a stablecoin balance and sign payment authorizations when asked.
• The resource server is whatever is being paid for: an API, a dataset, a tool endpoint, a piece of scraped web content. It sets the price, decides what counts as valid payment, and delivers the resource once payment clears.
• The facilitator is the piece most people find confusing at first. It is an optional but commonly used server that verifies signatures and submits transactions on behalf of the resource server, without ever holding user funds. Because a payment is a signed authorization, not a fund transfer to an intermediary, the facilitator can only broadcast exactly what the client already agreed to. It cannot redirect the money or change the amount. 

The dominant facilitator in production today is Coinbase's own CDP facilitator, which settles USDC fee-free on Base and Solana and includes compliance screening. The design is explicitly permissionless, though: several third-party facilitators exist, including PayAI, thirdweb, and self-hosted options built in Rust.

A "scheme" is the specific way money moves for a given request. x402 was built to support more than one, because a flat per-request fee does not fit every use case. 

exact is what almost every live x402 integration uses today. upto and batch-settlement exist specifically because paying on-chain gas for every single sub-cent request can cost more than the request itself, so the protocol needed a way to batch many tiny payments into one settlement.

x402 sits below the Model Context Protocol (MCP), which is the layer agents use to discover and call tools in the first place. MCP itself never moves money. When an agent calls a paid tool through MCP and hits a 402 response, an x402-aware wrapper handles the signing and retry automatically, so the agent's tool-calling logic never has to know payment happened at all. 

This composability extends further. Google's AP2 (Agent Payments Protocol) handles authorization, the "should this agent be allowed to spend this much on this thing" question, through an extension that uses x402 as its actual settlement rail. In this layered view, one protocol discovers (intents express what an agent wants), another authorizes the spend, and x402 handles the money actually moving. None of these are competing for the same job. 

The x402 Bazaar adds a discovery layer on top: a searchable catalog of paid endpoints that agents can query directly, indexed automatically the first time an endpoint successfully settles a payment. Coinbase describes it, fairly, as "more like Yahoo search than Google" at this stage: useful, but early.

x402 launched under Coinbase alone in May 2025. Governance moved quickly after that. In September 2025, Coinbase and Cloudflare announced plans to form a neutral x402 Foundation. That happened formally on April 2, 2026, when the Linux Foundation launched the x402 Foundation with 22 initial members, among them Adyen, AWS, Circle, Cloudflare, Coinbase, Google, Mastercard, Microsoft, Shopify, Solana Foundation, Stripe, and Visa. The spec itself is Apache-2.0 licensed and now lives in a foundation-controlled repository. 

On settlement, Base and Solana dominate. Base leads on cumulative volume and transaction count; Solana has claimed as much as 65% of transaction volume in some periods, helped by sub-second finality and fees near a fraction of a cent. Reference SDKs exist in TypeScript, Python, and Go, with community implementations in Rust. 

The adoption numbers themselves need a caveat, and it is an important one for anyone evaluating the protocol seriously. Coinbase has cited over 165 million transactions and roughly $50 million in cumulative volume. Independent analysis firm Artemis, however, found that as much as 86% of Solana's all-time x402 activity was "gamed," non-organic transactions designed to inflate volume rather than reflect real usage. Other estimates of genuine daily volume come in dramatically lower than the headline figures. Treat the growth statistics as directional, not audited.

x402 is not the only protocol trying to solve agentic payments, and it is worth being precise about what it actually competes with versus what it complements. 

The prevailing view across the ecosystem in 2026 is that these protocols are layered, not competing head-to-head. A fully autonomous flow might use one protocol to discover a service, AP2 to decide if the spend is authorized, and x402 to actually settle it. x402's real differentiators are being HTTP-native, permissionless by default, and, so far, having the most measurable real-world transaction volume of any of them, gamed or not.

x402's trust model is genuinely strong on one specific point: a facilitator cannot steal funds, because every payment is client-signed and any tampering fails signature verification. That said, two independent academic security papers published in May 2026 documented concrete, working attacks against production-style x402 deployments. 

The most serious findings involved missing idempotency protections. In one test, researchers achieved 248 successful HTTP payment grants from a single on-chain settlement by replaying requests, because the endpoint had no mechanism to bind one payment to one resource request. A separate test found that when a CDN cached responses without proper cache headers, unpaid requests received cached copies of paid content 100% of the time. Neither of these is a flaw in the cryptography; both are implementation gaps that responsible engineering teams need to close before treating x402 as production-hardened for anything beyond low-stakes experimentation.

There is also a structural centralization concern: Coinbase's own facilitator handles the large majority of live traffic today, and the spec's fallback to local verification is rarely implemented in practice. If that one facilitator has an outage, most live x402 endpoints go dark with it. 

None of this means the protocol is unsafe to build on. It means the failure modes are well documented, and the fixes (idempotency keys, cache headers, facilitator redundancy) are known and addressable by anyone integrating it carefully.

x402 turns a dormant HTTP status code into a working answer to a problem agentic AI was going to hit eventually: software that needs to pay for things without a human present. It is still young, its adoption numbers are inflated by non-organic activity, and its early security research has found real gaps that need closing. But the core design, gasless signed authorizations, non-custodial facilitators, and a chain-agnostic scheme system, is a genuinely sound foundation, and it already has the widest real infrastructure support of any competing agent-payment protocol. 

For Rango, the relevant part of this story is straightforward: as more agents earn and hold stablecoins across Base, Solana, and other chains through x402, the need to move that USDC wherever it is needed next only grows. If your agent (or you) end up holding stablecoins across multiple chains after an x402 transaction, you can consolidate or route them today through Rango Exchange.

• x402 whitepaper and documentation, Coinbase Developer Platform

• x402 Foundation launch announcement, Linux Foundation

• EIP-3009: Transfer With Authorization, Ethereum Improvement Proposals

• Model Context Protocol documentation, Anthropic

• Agent Payments Protocol (AP2) overview, Google

• x402 GitHub repository, x402 Foundation

• Five Attacks on x402 Agentic Payment Protocol

• Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments