x402 — paying AI agents per API call, explained

A brief history of 402

HTTP/1.1 (RFC 2616, 1999) defined a long list of status codes. Most of them — 200, 301, 404, 500 — are deeply familiar. One of them is not. Status code 402 was reserved as Payment Required, and the spec explicitly noted it was not currently used. The intent was always to let servers say no, please pay first, but the web in 1999 had no ergonomic way to actually move money in response to an HTTP request. So 402 sat there for almost three decades, unused.

Coinbase revived 402 in 2025 with a standard they called x402. The thesis is simple: stablecoins (especially USDC on fast L2s like Base) finally make per-request micropayments practical. A server can return HTTP 402 with a structured payment requirement, the client can sign and submit a transfer, and the retry can carry proof. No third-party billing, no payment processor in the middle, no API keys.

The wire format

x402 is intentionally a thin protocol. A server that wants to charge for a request returns HTTP 402 with a JSON body that names the chain, the asset, the amount in atomic units, the recipient address, and a one-shot nonce. Roughly:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "scheme": "x402-eip3009",
  "chain": "base",
  "chainId": 8453,
  "asset": "usdc",
  "assetAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "amount": "2000000",
  "recipient": "0x...",
  "nonce": "0xabc...",
  "validBefore": 1747200000
}

The amount is in atomic units. USDC has 6 decimals, so two dollars is the integer 2000000. The client signs an EIP-3009 transferWithAuthorization off-chain, then retries the original request with the signed payload in an X-Payment-Proof header.

POST /mcp HTTP/1.1
X-Payment-Proof: <base64-signed-eip3009-authorization>
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{...}}

The server verifies the signature, posts the authorization on-chain (or queues it), and returns the original 200 response. Total time: a few seconds on Base, no API key handed out, no card on file.

Why this matters for agents

Until x402, every paid API needed an account, an API key, a usage meter, and a monthly invoice. That was fine for a human developer. It is wrong for an AI agent. An autonomous agent that wants to call a hundred small services should not be signing up for a hundred billing portals.

x402 collapses the whole stack. The agent has a wallet. The wallet has USDC. The service quotes a price per call. The agent pays. Both sides walk away with no ongoing relationship beyond the single request. This is the API economy for machines, the same way email was the API economy for people.

How quik.space uses x402

quik.space exposes an MCP server at /mcp with three tools: upload_file, get_file_info, and extend_file. The first two have a free tier (uploads up to 100 MB are free, info lookups are always free). The third is paid — $2 in USDC on Base per 30-day extension.

When an agent calls extend_file with no payment header, the server returns 402 with the structured requirement. The agent signs the EIP-3009 authorization, retries with X-Payment-Proof, and the server bumps the file's expires_at column. No subscriptions. No API keys. No support tickets. The full protocol details and a complete curl example live on the AI agents page.

The bet

x402 is the smallest possible protocol for paid HTTP. That is its strength. It is layered on top of HTTP and on top of stablecoins, adding the bare minimum to make per-request payment work. If agent-driven traffic becomes a meaningful fraction of the web in the next few years — and a lot of smart people are betting it will — x402 is the most plausible payment rail for that traffic.

quik.space is built for that future. The file-sharing world is just a useful starting point, because every agent eventually needs a place to put a generated file.