HTTP 402 Was Always There. We Just Weren't Ready.
There's a status code sitting in every HTTP implementation, in every language, in every server framework on earth. It's been there since 1991. It was designed to do one thing: tell a client that payment is required before a resource will be served.
For 34 years, it went unused. Not because the idea was wrong, but because the infrastructure to execute on it didn't exist. Payments were slow. They required accounts, sessions, KYC, chargeback windows, and a human sitting in the loop. The web moved on and 402 collected dust.
x402 is the protocol that finally makes 402 mean what it was always supposed to mean.
The Problem x402 Actually Solves
When you strip away the crypto framing, x402 addresses a fundamental gap in how the web handles transactions.
Today, if a service wants to charge for an API call, it issues API keys. You register an account, pick a billing plan, add a credit card, wait for provisioning, and eventually you get a key you embed in headers. The payment and the request are completely decoupled. The payment happened days ago in a separate flow, and the request just carries a credential that proves you already paid.
This works for humans, butit's not ideal for machines.
An AI agent that needs to call a weather API, then a mapping service, then a translation endpoint, then a vector database, cannot reasonably maintain billing accounts across dozens of providers. It can't click "Accept Terms". It can't enter a credit card. And even if you delegated those credentials to it, you'd be handing it keys that could drain an account rather than authorizing a specific transaction.
x402 addresses this. The HTTP 402 response tells the client exactly what payment is needed: the amount, the currency, the network, the recipient. The client signs a payment authorization, retries the request with a X-PAYMENT header, and the server delivers the resource once settlement is confirmed. One round trip. No accounts. No sessions. No API keys.
The payment is the credential.
What Came Before, and What's Competing Now
x402 wasn't born into a vacuum. Several protocols have been trying to solve adjacent parts of what x402 aims to solve.
L402 (formerly LSAT) came from the Lightning Network community. It uses the same 402 status code concept, denominated in Bitcoin satoshis over Lightning. It's elegant for micropayments and has deep roots in the Bitcoin/Lightning ecosystem. Where it struggles is with the volatility and tooling overhead of Lightning: channel liquidity, invoice management, and the relative immaturity of Lightning developer infrastructure. L402 is the right answer inside the Lightning-native world; it's harder to make work in the broader web.
MPP (Machine Payments Protocol), developed by Stripe with Tempo, takes the opposite approach. It's multi-rail: stablecoins, fiat, cards, and Lightning. It's built on Stripe's enterprise infrastructure, which means it inherits Stripe's distribution and compliance posture. The tradeoff is that "multi-rail" also means "Stripe's standard processing fees apply.". For $0.001 API calls, that math doesn't work.
Nevermined focuses on privacy-first agent payments, with stronger controls around who can see what a payment was for. More of a complement than a competitor for most use cases.
x402 sits in the middle of this field with a specific set of bets: stablecoin-first (USDC), onchain settlement, zero protocol fees, and an open standard not owned by any single company. Coinbase open-sourced it in May 2025, and by April 2026 it moved to the x402 Foundation under the Linux Foundation, with 22 member organizations including Stripe, Google, AWS, Microsoft, Visa, Mastercard, Shopify, and American Express.
That last sentence is worth re-reading. The incumbents of global payments infrastructure are sitting at the table.
Why Web2 Should Care More Than Web3
We tend to frame x402 as a crypto story, but we believe that framing undersells it.
x402 solves a problem that Web2 has had for years and has just learned to live with: the cost of billing infrastructure relative to the value of the transaction.
Today, if you want to charge $0.002 for a single API call, your options are roughly: batch the calls until you have enough to justify a monthly invoice, build a credit system where users pre-fund a balance, or eat the overhead and just offer free tiers. You cannot profitably process a $0.002 card transaction. Stripe's floor is $0.30 plus 2.9%. That's a 150x markup on a two-mill transaction.
This is why most of the API economy runs on credit systems, free tiers, and monthly subscriptions rather than genuine pay-per-use. The billing model is a technical constraint masquerading as a product decision.
x402 with USDC on a Layer 2 changes the math. Gas fees on Base run $0.001 to $0.05. On Solana, $0.00025. A $0.002 transaction is now economically viable to process. This means API providers who have always wanted to offer true consumption-based pricing, but couldn't justify the infrastructure, now have a path.
For Web2 companies, this isn't about becoming crypto companies. It's about getting a billing model that matches what they're actually selling.
The Obvious Part: AI Agents Change Everything
The agent economy isn't a prediction anymore... it's becoming a reality.
By Q1 2026, x402 was processing 165 million transactions with 69,000 active agents and roughly $50 million in cumulative volume. That growth rate didn't come from humans manually approving payments. It came from agents paying agents, autonomously, at machine speed.
Here's what the agent economy needs from a payment protocol that the legacy system cannot provide:
No human in the loop. An agent running a research task at 3am cannot pause to wait for a billing approval. The payment needs to happen as part of the HTTP request lifecycle.
No credential exposure. Giving an agent an API key is giving it a blank check up to your plan limit. Giving it a wallet with a spending policy means each payment is cryptographically authorized for exactly that transaction.
Auditability by default. Every x402 transaction is onchain. If an agent makes a payment, there's a verifiable record. This matters enormously for enterprise deployments where finance teams want to see exactly what agents spent money on.
Composability. When Agent A pays Agent B, and Agent B pays Agent C to complete a subtask, the payment graph tells you the full story of what happened. You can build settlement, dispute resolution, and revenue sharing directly into the protocol layer rather than bolting it on top.
The traditional payment stack was built for humans making conscious purchasing decisions. Agents don't work that way. x402 does.
Why Chains Need to Get Behind This Standard
Every blockchain that wants to be part of the agent economy has a decision to make: be a destination for x402 payments or be left out of the market that's forming.
This isn't speculative. The transaction volume concentration is already happening. Solana captured 67% of x402 transactions in Q3 2025, handling roughly 518,000 daily transactions versus Base's 505,000 by January 2026. The reason is simple: Solana's typical x402 payment costs $0.00025, compared to $0.01 to $0.05 on Ethereum L2s. At the transaction volumes agent workflows generate, that 40x to 200x cost difference compounds fast.
For a chain, the case for adopting x402 comes down to three things.
First, agent transactions are high-frequency and predictable. Unlike speculative trading volume, API payment flows are relatively stable and scale with real economic activity. That's the kind of volume chains should want.
Second, x402 is a Linux Foundation standard with 22 enterprise member organizations. A chain that's not on the supported network list is not a chain those organizations are going to route payments through. The window to be on that list at the ground floor is finite.
Third, the alternative is fragmentation. If every chain builds its own agent payment protocol, the developer experience becomes impossible. An agent developer choosing a payment stack doesn't want to think about which chain their counterparty supports. A standard wins because it removes that friction from both sides. Chains that invest in x402 compatibility invest in the network effects of the whole ecosystem, not just their own corner of it.
The bet on x402 is a bet that the agent economy will be large enough that the payment layer becomes critical infrastructure. Given what we've seen in the first year of live volume, that bet looks increasingly one-sided.
Where This Goes
HTTP 402 sat unused for 34 years because the conditions for it to work weren't there. Payments were too slow, too expensive, too human. The web built workarounds, and we got so used to those workarounds that we stopped noticing they were workarounds.
x402 doesn't invent a new concept, but delivers on a concept that was always correct. The protocol machinery that makes it work, fast blockchains, stablecoins, cryptographic authorization, is new. The underlying idea that a web resource should be able to state its price and receive payment in the same request is 34 years old.
The open standard. The enterprise backing. The agent volume. These are converging signals.
The infrastructure for machine-to-machine commerce is being built right now, and it's being built on HTTP 402.
