The x402 protocol in 2026: history, mechanics, and what LLM4Agents is shipping on top of it

HTTP status code 402 was reserved in the 1991 HTTP/1.0 specification and labelled "Payment Required" — and then nothing happened with it for thirty-four years. In May 2025, Coinbase open-sourced a working protocol behind that status code. In April 2026, that protocol joined the Linux Foundation with twenty-two founding members including Google, AWS, Stripe, Visa, Mastercard, American Express, Microsoft, Shopify, Cloudflare, Polygon, the Solana Foundation and the major card networks. The 402-day timing was on purpose. This post explains exactly what x402 is, how it works at the byte level, why it became a standard in 2026, and the x402-native layer LLM4Agents is about to put on top of it.

What x402 actually is

x402 is an open HTTP payment protocol. A client sends a normal HTTP request. If the server requires payment, it responds with 402 Payment Required and a header telling the client what to pay, where, and on which chain. The client signs an authorization, retries the same request with a payment header attached, and the server delivers the resource once a facilitator confirms the transfer on-chain. The whole exchange runs over standard HTTP, takes one extra round trip in the worst case, and works the same way whether the caller is a browser, a curl script, or an autonomous agent.

The protocol is intentionally minimal. There is no account creation, no API key, no monthly invoice, no subscription tier. The payment is the credential. The signed authorization simultaneously authenticates the caller, meters the request, and produces a receipt. Three concerns collapsed into one round trip.

The spec lives at github.com/coinbase/x402. SDKs ship in TypeScript, Python and Go, with HTTP middleware for Express, Hono, Next.js, axios and fetch.

From reserved status code to Linux Foundation standard

HTTP 402 first appeared in RFC 1945 in May 1996, formalising what HTTP/1.0 had reserved in 1991. The intent was always digital payments. The mechanism never materialised. Native browser micropayments were attempted twice (Flattr, the W3C Web Payments group) and both initiatives stalled because the settlement layer didn't exist — credit-card rails were too expensive per call and too slow per settlement for what 402 wanted to be.

Stablecoins changed that arithmetic. By 2024, USDC and USDT settled on multiple chains in seconds for fractions of a cent, and EIP-3009 (deployed natively on USDC and EURC) made it possible for a wallet to sign a transfer authorization that any third party could submit on-chain. The pieces were there; someone had to assemble them.

Coinbase did, and shipped x402 publicly in May 2025. Adoption through the second half of 2025 was uneven — a burst of experimentation in November and then a measurable drop in on-chain volume through early 2026 — but the institutional movement underneath the curve kept building. On 2 April 2026 ("4/02 day," a date the Linux Foundation chose with full knowledge of the joke), Coinbase donated x402 to the newly formed x402 Foundation, with founding intent from Adyen, AWS, American Express, Ampersend.ai, Base, Circle, Cloudflare, Coinbase, Fiserv, Google, KakaoPay, Mastercard, Merit Systems, Microsoft, Polygon Labs, PPRO, Shopify, Sierra, Solana Foundation, Stripe, thirdweb and Visa. The card networks and the major clouds in the same room is the part that matters: x402 is no longer a Coinbase project.

By late April 2026 the protocol had processed 165 million transactions across roughly 69,000 active agents, totalling about $50M in cumulative volume. Solana drove approximately 65% of 2026 volume. The on-chain numbers are off their November 2025 peak; the institutional adoption is not.

The flow, in bytes

The simplest x402 exchange has three actors: client (often an AI agent), server (the resource owner), and facilitator (an optional but recommended third party that handles on-chain settlement). The full exchange:

// 1. Client makes a normal request.
GET /v1/chat/completions HTTP/1.1
Host: api.example.com

// 2. Server responds 402 with payment terms.
HTTP/1.1 402 Payment Required
Content-Type: application/json
X-PAYMENT-REQUIRED: {"scheme":"exact","network":"solana-mainnet","asset":"USDC","amount":"0.001","payTo":"<recipient>","resource":"/v1/chat/completions"}

// 3. Client builds the authorization, signs it, retries the same request.
GET /v1/chat/completions HTTP/1.1
Host: api.example.com
X-PAYMENT-SIGNATURE: <base64-encoded signed authorization>

// 4. Server calls the facilitator: verify + settle.
// 5. Facilitator submits to the chain, returns confirmation.
// 6. Server delivers the resource.
HTTP/1.1 200 OK
Content-Type: application/json
X-PAYMENT-RECEIPT: <tx-hash>

{"choices":[...]}

That is the whole protocol on the wire. The interesting work is inside step 3 (what the client signs) and step 4 (what the facilitator does).

The signing schemes, in detail

x402 separates the wire protocol from the on-chain mechanism via what it calls "schemes." Three matter today.

EIP-3009 (USDC, EURC on EVM chains). Both tokens implement transferWithAuthorization natively in their contracts. The client signs an EIP-712 typed-data payload with seven fields: from, to, value, validAfter, validBefore, nonce, and the signature over the EIP-712 typed-data hash. The nonce is a random 32-byte value, not a sequential counter — this is the design choice that lets one wallet have many in-flight authorizations in parallel without collision, which is exactly what an agent making concurrent requests needs. The facilitator (or anyone) submits the authorization to the token contract; the contract verifies the signature and transfers the funds. The client never sees gas, never holds the native token, never broadcasts a transaction.

Permit2 (any ERC-20). For tokens that do not implement transferWithAuthorization natively, Uniswap's Permit2 contract provides equivalent functionality on top: the user grants Permit2 a one-time approval, then signs gas-free transfer messages routed through Permit2. The trade-off is an initial approval transaction the user pays for once; after that, every transfer is gas-free for them. This is what the Coinbase CDP facilitator uses to support USDT, DAI, and any other ERC-20 that does not natively support EIP-3009.

Solana SPL (USDC, USDT on Solana). Solana does not have EIP-3009 because Solana does not have EIP anything. The x402 Solana scheme uses a partial transaction: the client constructs an SPL token transfer, signs it as the payer of the token amount, and sends the partial transaction to the facilitator. The facilitator co-signs as fee payer and submits to a validator. Functionally identical to EIP-3009 from the client's perspective — no SOL needed, no manual broadcast — but the on-chain primitive is different.

The decoupling matters: when an x402 endpoint adds support for, say, Sui or Aptos, only the scheme module changes. The HTTP-level protocol stays exactly the same.

What the facilitator actually does

The facilitator is the single component in x402 that has any real complexity. Its job is to take a signed authorization, verify it cryptographically and economically, submit it to the appropriate chain, and report back to the resource server whether the transfer succeeded. Specifically:

Verification. Recover the signer from the signature, check the nonce has not been used, check validAfter and validBefore bracket the current time, check the signer has enough balance, check the asset address matches what the resource server requested. None of these requires touching the chain; all of them prevent wasted submissions.

Settlement. For EIP-3009, call transferWithAuthorization on the token contract. For Solana SPL, co-sign as fee payer and submit. For Permit2, route through the Permit2 contract. The facilitator pays the gas; the resource server pays the facilitator a small fee bundled in the protocol price.

Confirmation. Wait for inclusion (1-2 slots on Solana, 1-2 blocks on most EVMs), return the transaction hash to the resource server. The server then ships the resource.

Anyone can run a facilitator. The Coinbase CDP runs the largest one today, supporting USDC and EURC via EIP-3009 on Base, Polygon, Arbitrum, World and Solana, plus arbitrary ERC-20s via Permit2 and SPL tokens on Solana, with a free tier of 1,000 transactions per month. Second State runs an open-source facilitator. Solana Foundation's Pay.sh registry catalogs community facilitators. The protocol is one-to-many on this dimension by design.

The 2026 ecosystem map

The state of x402 in May 2026 is best read as a small number of large dots:

Coinbase CDP — first-party facilitator, the reference implementation, the largest catalog of supported chains and tokens. Free tier with 1,000 tx/month then usage-based.

Pay.sh (Solana Foundation + Google Cloud, launched 5 May 2026) — an API gateway built on x402 that fronts Google Cloud services (BigQuery, Gemini, Vertex AI) plus 50+ community APIs. Pay.sh is the first large-scale "many-services-behind-one-x402-gateway" deployment and the proof point for the protocol's marketplace pattern. We covered it last week.

Bankr x402 Cloud (launched on 4/02 day) — a turnkey hosted x402 deployment for businesses that want to monetize APIs without standing up their own infrastructure.

Circle Nanopayments (live on mainnet 11 May 2026) — not x402-native but adjacent: gas-free USDC transfers down to $0.000001, across eleven blockchains. The economic model x402 makes possible at the per-request layer, Nanopayments makes possible at the wallet-to-wallet layer.

Cloudflare — a founding x402 Foundation member; the company that built the global edge infrastructure x402 will be served from for the vast majority of users.

The on-chain volume numbers tell a more honest story than the institutional press release. November 2025 saw a sharp burst — a few zealous early adopters, some bot traffic, a fair amount of demo-ware. The first quarter of 2026 saw a measurable drop as that early enthusiasm settled. What did not drop is the founding-member list, the SDK release cadence, or the facilitator count. The category is in the gap between "novelty" and "infrastructure," and it is the same gap SSL spent in 1996–1997 before becoming inevitable.

Why x402 is the big think for 2026

Four reasons we are betting on it as a primary integration target rather than a side experiment.

The payment is the credential. Every alternative to x402 — API keys, OAuth tokens, JWT, mTLS, signed URLs — solves authentication and metering separately and bills monthly. For an autonomous agent that calls 500 endpoints in a workflow, that is 500 onboarding flows, 500 quota tables, 500 invoices. x402 collapses all of it into the same round trip as the request itself. The savings compound non-linearly with the number of services an agent talks to.

HTTP-native, no new primitives. x402 does not introduce a new transport, a new addressing scheme, a new identity layer, or a new client API surface. Any HTTP client speaks it; any HTTP server can adopt it incrementally. There is no parallel internet to bootstrap. Compare with WebPayments, Lightning Network for HTTP, or the various L2-specific payment SDKs — all of those require both ends of the wire to leave the standard HTTP stack. x402 does not.

Multi-chain by design. The scheme separation means an agent can pay in USDC on Solana to one endpoint, USDT on Polygon to another, and EURC on Base to a third, with the same SDK, in the same loop, against the same facilitator. The chain is a presentation-layer detail, not an architectural commitment.

Institutional gravity. Visa, Mastercard, American Express, AWS, Google, Stripe, Microsoft, Shopify and Cloudflare are not founding members of standards bodies for protocols they think will fail. The on-chain volume curve is noisy; the institutional adoption curve is not.

The gap LLM4Agents is closing

Today, x402 facilitators are separate from the LLM and tool layer. An agent that wants to use x402 has to assemble: an x402 client SDK, a wallet keypair, an LLM provider (probably with its own API key and pre-paid balance), an MCP server (probably with another API key), and the glue between them. Five integrations to do one thing. The agent's wallet does not pay the LLM; the LLM does not know what the agent paid the tool; the tool does not know what the agent paid the next tool.

We think the right shape is the inverse: one wallet, one SDK, one facilitator, x402 everywhere. The agent funds a single non-custodial wallet on Solana or Polygon. The same wallet pays for LLM inference, MCP tool calls, third-party x402 endpoints, and any future x402 service the agent discovers, with the same signing path and the same per-request economics. That is the layer LLM4Agents is shipping.

What we are shipping, specifically

Three concrete additions to the platform, all aligned with the standard x402 spec so anything we ship is interoperable with the rest of the ecosystem.

1. x402-native LLM inference

The existing OpenAI-compatible endpoint already accepts requests authenticated by a pre-funded agent balance. The new mode accepts the same endpoint with an X-PAYMENT-SIGNATURE header instead. The agent (or the SDK on its behalf) signs an EIP-3009 or SPL authorization for the exact cost of the completion — quoted in the 402 response — and retries. No pre-loaded balance, no API key, no account.

The two paths coexist: an agent with a registered wallet and a topped-up balance still uses the cheaper, lower-latency balance path; an unregistered agent calling cold can pay strictly per-completion via x402. The fallback ladder is automatic — exhaust balance, fall through to x402, fall through to error — and the SDK handles it transparently.

2. x402-native MCP tools

The MCP server at mcp.llm4agents.com/mcp exposes browser, search, image generation and the rest of the tool catalog. From the next release, every tool call returns 402 by default if the request is unauthenticated, with the price quoted per-call. An agent can pay $0.0002 for a single search, $0.005 for a scrape, $0.04 for a 1024×1024 image, with no upstream account or contract. The same signing flow that pays for inference pays for tools.

The MCP-over-x402 combination is what makes a fully composable agent economy possible. A third-party MCP server can charge per call; an agent can discover the server, read its catalog, and start paying — all without a human in the loop and all routed through the LLM4Agents facilitator.

3. SDK with first-class x402 client

The @llmforagents/sdk (TypeScript) and llm4agents-sdk (Python) gain a top-level x402 module that the agent can use to pay any x402 endpoint, not just ours:

import { LLM4AgentsClient } from '@llmforagents/sdk';

const client = new LLM4AgentsClient({
  walletPrivateKey: process.env.AGENT_KEY!,
  chain: 'solana',                    // or 'polygon', 'base'
});

// Pay any x402 endpoint, anywhere on the internet.
// The SDK handles 402 detection, signing, retry, and receipt parsing.
const response = await client.x402.fetch(
  'https://some-third-party-api.example/v1/data',
  { method: 'POST', body: JSON.stringify({ query: '…' }) }
);

// Or use the high-level helpers for our own endpoints.
const completion = await client.chat.completions.create({
  model: 'anthropic/claude-sonnet-4',
  messages: [{ role: 'user', content: '…' }],
  paymentMode: 'x402',                  // pay per-call, no balance needed
});

Under the hood, the SDK constructs the EIP-712 typed-data payload (EVM) or the SPL partial transaction (Solana), signs with the agent's key, attaches X-PAYMENT-SIGNATURE, retries, surfaces the receipt, and exposes the tx hash on the response. The facilitator on the settlement side is ours by default — multi-chain Solana, Polygon, and Base, supporting USDC and USDT — but can be configured to any compliant x402 facilitator including Coinbase CDP. The SDK is the standard x402 client, not a proprietary fork.

4. LLM4Agents as a facilitator

We are also running our own facilitator and registering it with Pay.sh and the Linux Foundation's facilitator registry. This is the dimension where being protocol-native pays off: an agent built on our SDK can pay a Pay.sh-listed endpoint, a Coinbase-CDP-fronted endpoint, or our own endpoint with identical code. We are not building a walled garden; we are building one node in an open mesh.

Use cases this combination enables

Anonymous agent inference. A throwaway agent — a one-shot scraper, a CI bot, a research process spun up by a long-running agent — calls the LLM endpoint with x402 and no prior registration. Pays per-completion, gets the answer, dies. No signup latency, no account housekeeping, no key rotation.

Composable per-request economics. An agent answers a single user query that requires four tool calls (search, scrape, summarize, image) and one completion. Each step settles independently in stablecoin. The agent's wallet is debited five times in the same conversation, each amount priced exactly. The operator gets a receipt trail rather than an aggregated bill.

Agent-to-agent payments. Agent A offers a service (a research pipeline, a translation, a data-cleaning routine) and exposes it as an x402 endpoint. Agent B discovers it, pays for it from its own wallet, consumes the result. Both ends use the LLM4Agents SDK. There is no payment platform in the middle — the protocol is the platform.

Third-party MCP server monetization. Anyone with a useful tool can expose it as an x402-secured MCP endpoint, register the URL in the LLM4Agents registry (or any other registry), and start collecting per-call revenue. Agents on our SDK pay it natively. The barrier to becoming an agent-economy seller drops to writing the code.

Continuous services with per-second economics. An agent that subscribes to a streaming data source, a live transcription, or a long-running compute job can extend its x402 authorization periodically rather than pre-committing to a tier. Combined with Firecracker-snapshotted compute and Circle Nanopayments at the wallet layer, the granularity of "what an agent rents from the internet" drops to the second.

Honest tradeoffs

x402 is the right primitive for the per-request economics autonomous agents demand. It is not the right primitive for every workload. A few caveats we want stated plainly.

Latency. A cold 402-and-retry adds one extra round trip and the facilitator's verification step. For an inference call that already takes 500ms, the overhead is in the noise. For a tool call that returns in 30ms, the protocol overhead is the cost. We recommend pre-funded balance for very high-frequency, very short-latency workloads, and x402 for everything where the per-call price matters more than the marginal milliseconds.

Facilitator centralization. A facilitator is a trusted (but verifiable) middleman. The protocol is one-to-many on this dimension — anyone can run one and clients can pick — but in practice today most volume runs through a handful. The right response is to keep the protocol spec genuinely open, run multiple facilitators, and let the market keep them honest. We are running ours; we encourage you to run yours.

On-chain volume volatility. The 2026 numbers are off the November 2025 peak. We do not think this invalidates the protocol; we think it reflects the absence of the platform pieces — gateway-grade SDKs, signed wallet identities, agent-native tools — that this announcement starts to deliver. We will publish the volume on our facilitator transparently.

Timeline

The x402-native LLM endpoint and the SDK x402 module enter closed beta with selected agent operators in the next two weeks. The MCP per-call x402 mode and the public facilitator registration land within the month. Full general availability and Pay.sh listing are targeted for early Q3 2026. If you want early access — particularly if you are running an agent that talks to ten or more external services and you are tired of managing ten API keys — get in touch through the registration endpoint below.

x402 spent thirty-four years as a reserved status code. The next twelve months are the ones that decide whether it becomes part of the default HTTP toolbox or stays a curiosity. We are betting it becomes the default, and we are building the agent layer that bet implies.