Payment Required: Inside x402, the HTTP-Native Settlement Standard for AI Agents

An autonomous AI agent needs to fetch paid data — a premium weather feed, a real-time price API, a proprietary model endpoint. To a human, this is trivial: enter a credit card number, get API credentials, call the endpoint. For a software agent, every step in that flow assumes a legal identity, a billing address, a human-operated browser. The agent has none of those.

x402 sidesteps the entire account-and-credential stack by embedding payment into the HTTP request itself. A resource server returns 402 Payment Required with instructions; the agent signs a stablecoin authorization into a header and retries. No accounts. No OAuth. No pre-registration. The chain settles it. As of March 2026, this has already processed 165 million transactions on Base and Solana with roughly $600 million in annualized volume.

Here is the exact protocol — and where its tradeoffs live.

HTTP 402’s 30-Year Vacancy

HTTP 402 was reserved in RFC 1945 (1996) with a single line: “reserved for future use.” Every HTTP library has dutifully carried it forward for three decades without a standard implementation. The intent was clear — “you need to pay to get this resource” — but the web’s credit card infrastructure never converged on a machine-readable payment format.

The result was a proliferation of one-off payment gates: OAuth token grants, API keys tied to billing accounts, subscription tiers with static credentials. These work for human users. They don’t work for agents that spin up on-demand, serve requests in milliseconds, and are economically viable only at per-query granularity.

x402 defines what HTTP 402 should have meant all along: a structured response body carrying the exact payment requirements, and a matching request header carrying the signed authorization.

The Four-Step Exchange

⬢ loading artifact…

The protocol is a single round-trip retried once with payment attached:

Step 1 — Initial request. The agent sends a standard HTTP GET with no payment context. This probes whether the resource is free. If the server returns 200, no payment needed.

Step 2 — Payment challenge. The server returns 402 Payment Required with a PAYMENT-REQUIRED header. Decoded from base64, it’s a JSON object specifying the amount (in USDC), the destination address, the chain (expressed as a CAIP-2 identifier: eip155:8453 for Base), a maximum price, and a timestamp window (validAfter, validBefore).

Step 3 — Sign, don’t submit. The agent constructs an EIP-3009 transferWithAuthorization message — not a transaction — and signs it with EIP-712. The agent never submits anything to the blockchain. No ETH. No mempool. This is a pure signing operation.

Step 4 — Signed retry with delivery. The agent base64-encodes the signed authorization into an X-PAYMENT header and retries the request. The server (via its facilitator) verifies the signature, submits the authorization on-chain, and returns the resource with a settlement receipt in X-PAYMENT-RESPONSE.

Total round-trip: 1.5–2 seconds. On Solana, 400 milliseconds.

EIP-3009: The Authorization That Travels in a Header

EIP-3009 is a USDC extension standard implementing transferWithAuthorization. The function signature:

function transferWithAuthorization(
    address from,
    address to,
    uint256 value,
    uint256 validAfter,
    uint256 validBefore,
    bytes32 nonce,
    uint8 v, bytes32 r, bytes32 s
) external;

The v, r, s values are an EIP-712 signature over the struct { from, to, value, validAfter, validBefore, nonce }. When the USDC contract receives this call, it verifies that the signature was produced by from, checks that block.timestamp is within [validAfter, validBefore], confirms the nonce hasn’t been used for this address, and executes the transfer.

This is fundamentally different from the ERC-20 approve + transferFrom two-step: there’s no allowance state, no prior on-chain setup, and no replay surface beyond the timestamp window. A signed authorization with validBefore = now + 60s expires in one minute whether it’s used or not.

The nonce in EIP-3009 is not a sequential counter (as in EVM transactions) but a 32-byte random value. The USDC contract tracks used nonces per address in a _authorizationStates mapping. Because nonces are random, multiple authorizations can be prepared in parallel with no ordering constraint — useful for agents making concurrent API calls.

The Facilitator: Why the Agent Doesn’t Need Gas

The agent’s signed authorization is valid, but who submits it on-chain? The answer is the facilitator — a service that holds ETH for gas, verifies the EIP-712 signature and timestamp window, and calls transferWithAuthorization on behalf of the server.

This is the architectural key. From the agent’s side:

• Only USDC is needed (not ETH or any native L2 token)
• No wallet state is maintained across requests
• No nonce management

From the facilitator’s side:

• Coinbase’s hosted facilitator: 1,000 transactions free per month, then $0.001/transaction
• On Base, gas costs roughly $0.0001–0.0003 per transaction, so the facilitator earns ~$0.0007–0.0009 margin at the $0.001 rate
• The facilitator carries the replay risk: if it submits an authorization after validBefore, the USDC contract rejects it and the facilitator eats the gas cost

Any party can run a self-hosted facilitator. The x402 spec is open; Coinbase’s facilitator is the dominant one today because it’s the default in the SDK, not because it’s required.

Production Numbers

As of March 2026:

• 165 million cumulative transactions (119M on Base, 35M on Solana)
• ~$600 million annualized payment volume across all chains
• ~$28,000 daily volume — suggest a predominantly micropayment profile
• Zero protocol fees — only blockchain gas and optional facilitator fees apply

Five named production deployments account for most of the volume: Coinbase Agent.market, Stripe Machine Payments, CoinGecko paid API endpoints, Circle Wallets reference workflow, and the Cloudflare Agents SDK. The Solana integration uses SPL tokens and the Solana Programs Library rather than EIP-3009, but the HTTP header format is identical.

x402 vs ERC-4337 vs AP2

Three payment architectures now compete for AI agent commerce. They have different trust models and different failure modes.

ERC-4337 Paymasters solve a different problem: gas abstraction for smart accounts. A paymaster sponsors the gas for a UserOperation, letting agents submit on-chain transactions without holding ETH. This is the right tool when the agent needs to make arbitrary on-chain calls — approve a token, call a DeFi contract, execute a swap. The cost is the ERC-4337 bundler overhead (~50k gas), the alt-mempool latency (2–5 seconds), and the requirement for a smart account. For HTTP API payments, ERC-4337 is architecturally heavier than the task warrants. (See The Paymaster’s Bargain for a full treatment.)

AP2 mandates (Google’s Agent Payments Protocol) require the LLM to select the payment target before the mandate is signed. This creates a pre-authorization surface: an injected merchant listing can redirect the mandate to an attacker’s address before any cryptographic commitment. x402 inverts this — payment is authorized only after the server’s 402 response identifies the target address. There’s no pre-selection step for injection to exploit. (See The Mandate Gap.)

x402 is HTTP-native: the agent pays for a specific URL, a specific amount, to a specific address, in a single exchange. No smart account required. No alt-mempool. No token approval state. The scope is narrow — HTTP resources, not arbitrary on-chain actions — and that narrowness is a feature.

The table makes the tradeoff visible: x402 is fast and injection-resistant for HTTP use cases but has no dispute resolution and relies on a centralized facilitator for production volume.

What Engineers Need to Build

A minimal x402 client needs three things:

1. A USDC balance. The agent wallet holds USDC on the target chain. No ETH required.

2. EIP-712 signing. The agent signs the transferWithAuthorization struct. Any EIP-712-capable signer works: ethers.js, viem, or a cloud KMS with EVM signing support.

3. Header handling. Parse the PAYMENT-REQUIRED header from a 402 response, construct the X-PAYMENT header with the signed authorization, and include it on the retry.

The server side needs a facilitator connection. The Coinbase facilitator is free for 1,000 requests/month; self-hosting requires running a service that can call transferWithAuthorization on-chain and handle nonce state.

EIP-7702 session keys (already deployed in Pectra) can pre-authorize an x402 client to sign within a spending limit, so the LLM doesn’t touch the signing key directly. See The Delegated Signer for how session-key bounds interact with agent wallet design.

The Gaps

Centralization. Today, roughly all production x402 volume flows through Coinbase’s facilitator. The spec is open and self-hosting is technically possible, but the network effect of a single dominant facilitator is a single point of control for payment verification and a surveillance surface for who-paid-for-what.

Privacy. Every x402 payment is an on-chain USDC transfer. The from, to, value, and timestamp are public and permanent. An agent that makes 1,000 API calls per day creates a detailed on-chain behavioral log. This is acceptable for many use cases and unacceptable for others (medical queries, legal research, competitive intelligence).

No proof of delivery. x402 proves the agent paid. It does not prove the server delivered what was promised. The X-PAYMENT-RESPONSE header carries a txHash confirming the USDC moved, not a content hash or service-level assertion. If the server takes payment and returns garbage, the dispute path is off-protocol. The agent is in the same position as a web user who paid a flaky API: the chain confirms payment; there’s no on-chain receipt for service quality.

Facilitator front-running. A malicious facilitator could, in principle, see the signed authorization before settlement and front-run it. The validBefore window limits the exposure window, but the facilitator is trusted to submit faithfully. In practice, Coinbase’s facilitator is reputational — this is a centralization risk, not a protocol property.

None of these gaps are fatal for the use cases x402 targets (paid API calls, data endpoints, AI tool access). They become significant if x402 is adopted for high-value or privacy-sensitive agent operations.

Takeaways

x402 works. The 165 million transactions and five named production deployments confirm it. For an AI agent that needs to call a paid HTTP endpoint — a data API, a model inference service, a premium tool — x402 is the lightest path: sign a header, pay USDC, get the resource. No accounts, no ETH, no bundler queue.

The architecture is sound at the protocol level: EIP-3009’s per-authorization nonces eliminate replay risk, the timestamp window bounds exposure, and the injection surface is structurally smaller than mandate-based approaches. The current deployment’s centralization in Coinbase’s facilitator is a business reality, not a protocol constraint — and one that will likely change as volume grows.

The remaining gap is delivery verification. Paying for HTTP access and verifying what was delivered are separate problems, and x402 solves only the first. That boundary is where the next generation of agent payment infrastructure will need to extend it.