x402

The open, neutral standard that finally activated HTTP 402 “Payment Required” — turning the internet’s oldest reserved status code into a native payment layer for AI agents and applications.

HTTP-native • Stablecoin-first • Machine-to-machine

What is x402?

x402 is an open payment protocol built directly on the HTTP protocol. It reuses the long-dormant HTTP status code 402 Payment Required so that any web resource (API, content, tool) can demand payment before serving a response.

Clients — especially autonomous AI agents — respond by attaching a cryptographically signed payment (usually stablecoins such as USDC) in a standard HTTP header. No accounts, no sessions, no API keys, no human checkout forms.

Zero protocol fees
Only underlying network fees
Instant settlement
Money moves at internet speed
Stateless
No accounts or credentials needed
Chain-agnostic
EVM, Solana, and expanding

History & Timeline

1990s (HTTP/1.0 → HTTP/1.1)
HTTP 402 is born — and immediately put to sleep
The status code “402 Payment Required” was reserved “for future use.” The vision was micropayments baked into the web itself. Technology (and human mental transaction costs) made it impossible for decades. Every other status code found a purpose; 402 became a running joke among engineers.
2015 – 2016
Coinbase’s early experiments
Brian Armstrong and later Balaji Srinivasan explored using 402 for Bitcoin micropayments (including work related to 21.co). The infrastructure was still too slow and expensive.
February 2025
Project inception
Initial commit of the x402 repository under Coinbase. Built by the Coinbase Developer Platform team (notably Erik Reppel and collaborators) using modern stablecoins, fast L2s, and programmable authorization (EIP-3009 / Permit-style).
6 May 2025
Public launch of x402
Coinbase officially launches the open standard. The protocol is open-sourced under Apache-2.0. Early collaborators include AWS, Anthropic, Circle and others. Designed from day one for AI agents that cannot fill out forms.
23 September 2025
x402 Foundation intent announced
Coinbase and Cloudflare jointly announce the intention to create a neutral foundation around the protocol so it is not controlled by any single company.
11 December 2025
x402 V2 released
Major upgrade: multi-chain by default, reusable sessions, better discovery, support for legacy rails, standardized headers (PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE).
2 April 2026 (4/02)
Linux Foundation formally launches the x402 Foundation
Coinbase contributes the protocol. Fitting date chosen deliberately. Initial cohort of ~22 organizations joins (Visa, Mastercard, Stripe, Google, Cloudflare, Circle, AWS, etc.).
14 July 2026
Operational launch of the x402 Foundation
Fully active under Linux Foundation governance with 40+ members spanning traditional finance, cloud, crypto and AI. Premier members include Adyen, American Express, Fiserv, Mastercard, Visa, Stripe, Shopify, Solana Foundation, Stellar, Ripple, Google, AWS and more.
Present (August 2026)
Production at scale
Tens of millions of transactions per month, multi-chain support, growing ecosystem of SDKs, facilitators, and agent frameworks. The dormant 402 status code is finally alive.

How an x402 Payment Works

The flow is deliberately minimal and HTTP-native. No extra round-trips beyond a normal request-response cycle when the client already knows the price.

  1. Client requests a protected resource.
  2. Server returns HTTP 402 + PAYMENT-REQUIRED header (Base64-encoded payment options: scheme, network, amount, asset, payTo address…).
  3. Client creates a signed payment payload (wallet / agent) and retries the same request with PAYMENT-SIGNATURE header.
  4. Server (or facilitator) verifies the signature and settles on-chain.
  5. Server returns the resource with HTTP 200 + PAYMENT-RESPONSE header containing settlement proof.

Sequence Diagram — Full Flow (with Facilitator)

sequenceDiagram participant C as Client / AI Agent participant S as Resource Server participant F as Facilitator participant B as Blockchain C->>S: HTTP Request (GET /premium) S-->>C: 402 Payment Required
PAYMENT-REQUIRED header Note over C: Select scheme & create
signed payment payload C->>S: Retry + PAYMENT-SIGNATURE header S->>F: /verify (optional) F-->>S: Valid S->>F: /settle F->>B: Submit transaction B-->>F: Confirmed F-->>S: Settlement proof S-->>C: 200 OK + Resource
PAYMENT-RESPONSE header

Simplified Direct Flow (no facilitator)

sequenceDiagram participant Client participant Server participant Chain as Blockchain Client->>Server: Request resource Server-->>Client: 402 + payment requirements Client->>Client: Sign payment (EIP-3009 / scheme) Client->>Server: Request + signed payload Server->>Chain: Verify & settle Chain-->>Server: Tx confirmed Server-->>Client: 200 + resource + settlement proof

Key Technical Details

  • Headers (V2): PAYMENT-REQUIRED (server → client), PAYMENT-SIGNATURE (client → server), PAYMENT-RESPONSE (server → client).
  • Schemes: “exact” (fixed amount) is the most common; “upto” and others exist for metered usage.
  • Primary assets: USDC and other stablecoins; extensible to any token and even traditional rails via facilitators.
  • Networks: Originally Base-focused, now multi-chain (EVM + Solana + more via CAIP-2 identifiers).
  • Facilitators: Optional services that handle verification and on-chain settlement so resource servers stay simple.
  • Governance: Now under the Linux Foundation’s x402 Foundation — neutral, open, multi-stakeholder.