x402 Protocol: HTTP 402 Machine-Native Micropayments Guide

Frequently Asked Questions

01.What is the x402 protocol and how does it differ from traditional web payments?

The x402 protocol is an open payment standard, open-sourced by Coinbase in May 2025, that repurposes the dormant HTTP 402 Payment Required status code to enable instant, machine-to-machine stablecoin micropayments directly over HTTP. Unlike traditional payment systems that require account creation, OAuth flows, subscriptions, and card credentials, x402 works through a four-step request-response handshake: the server returns a 402 with a signed payment invoice in the PAYMENT-REQUIRED header, the client constructs an EIP-712 authorization signature for USDC using EIP-3009 transferWithAuthorization, submits it via the PAYMENT-SIGNATURE header, and the server verifies through a facilitator and delivers the resource. No accounts, no PCI DSS card data, no human intervention required. Settlement finality on Base Layer 2 occurs within approximately 200 milliseconds at sub-cent transfer costs, enabling real-time machine-to-machine commerce at a granularity that traditional payment infrastructure cannot support.

02.Which blockchains does x402 support and what token standards are compatible?

x402 supports Base (primary), Ethereum mainnet, Polygon, Arbitrum, World, Avalanche, and Solana as of its current roadmap. On EVM chains, the protocol accepts USDC natively and any ERC-20 token that implements either Permit2 or EIP-3009 transferWithAuthorization, since both allow gasless authorization via signed messages rather than requiring a prior on-chain approve transaction. Chains are identified using CAIP-2 identifiers, for example eip155:8453 for Base. The x402 facilitator service handles gas sponsorship, so client agents never need to hold native gas tokens. Solana support uses a comparable signed-authorization pattern adapted for SPL tokens.

03.What security risks should engineers assess before deploying x402 endpoints in production?

Engineers must evaluate four primary risk categories before production deployment of x402 endpoints. First, replay attack surface: EIP-712 signatures must include a unique nonce, expiry timestamp, and chain ID to prevent signature reuse across sessions or networks. Second, facilitator trust: the current Coinbase facilitator is a semi-centralized service, so teams should implement fallback logic and monitor facilitator uptime. Third, spending cap enforcement: smart contract wallets used by agent clients must have daily spending limits enforced at the contract level, not only application logic, to cap blast radius from compromised agent keys. Fourth, rate-limit circumvention: while payment cost deters spam, zero-sum adversaries can drain an agent wallet through repeated 402 challenges; endpoints should implement per-wallet circuit breakers in addition to cost barriers. No formal third-party security audit from OpenZeppelin, Trail of Bits, or equivalent had been published as of early 2026.