What Is x402?

x402 is an open protocol that implements the HTTP 402 "Payment Required" status code for machine-native payments. It enables autonomous AI agents to pay for API resources using stablecoins on EVM-compatible blockchains — without accounts, API keys, or human intervention.

The protocol defines a standard request-response flow layered on top of HTTP. A server advertises pricing requirements through structured headers, a client signs a gasless payment authorization, and a facilitator settles the transaction on-chain. The entire exchange completes in a single HTTP round-trip after the initial 402 response.

x402 was created to solve a specific problem: AI agents need to consume paid APIs, but traditional monetization — API keys, OAuth tokens, billing accounts — requires human setup and cannot scale to autonomous operation. By making payment a native HTTP primitive, x402 allows any agent with a funded wallet to access any compatible service immediately.

The Core Payment Flow

Every x402 transaction follows seven steps:

1. Client requests a resource. A standard HTTP request (GET, POST, etc.) is sent to a protected endpoint. No authentication headers are included.

2. Server returns 402 with Payment-Required header. The response includes a base64-encoded Payment-Required header containing the price, accepted payment network (identified by CAIP-2 chain ID), token contract address, recipient (payTo) address, and a validity timeout.

3. Client signs an EIP-3009 transferWithAuthorization. The client constructs an EIP-712 typed data message authorizing a USDC transfer for the exact amount, then signs it with the agent's private key. No on-chain transaction is created at this point — only a cryptographic signature.

4. Client resubmits with Payment-Signature header. The original request is resent with an additional Payment-Signature header containing the base64-encoded signed authorization payload.

5. Facilitator verifies the signature and checks balance. The facilitator — a trusted intermediary — validates the EIP-3009 signature, confirms the payer has sufficient USDC balance, and verifies that the authorization parameters match the server's requirements.

6. Server returns the resource with Payment-Response header. The HTTP response includes the requested data (API response, file, etc.) along with a Payment-Response header containing a settlement receipt with the on-chain transaction hash.

7. Facilitator settles on-chain. The facilitator executes the transferWithAuthorization call on the blockchain. USDC moves directly from the payer's wallet to the recipient's wallet. The facilitator never takes custody of funds.

The client SDK (@x402/fetch) automates steps 2 through 4 transparently. From the developer's perspective, a paid API call looks identical to a standard fetch request.

Key Design Principles

Permissionless

No accounts. No API keys. No KYC. No registration. The only requirement to access an x402-protected resource is a funded wallet. The wallet address serves as the client's identity, and the signed payment serves as the authorization. This makes x402 inherently accessible to autonomous agents that cannot fill out forms, verify email addresses, or navigate onboarding flows.

Gasless

The agent never sends an on-chain transaction. It only produces a cryptographic signature — an off-chain operation that costs nothing and requires no native gas token (ETH). The facilitator sponsors all gas costs when submitting the transferWithAuthorization to the blockchain. This eliminates the need for agents to hold ETH, manage gas estimation, or handle transaction nonce conflicts.

Push Payments

x402 payments are push-based authorizations, not pull-based charges. The payer explicitly signs each payment for a specific amount to a specific recipient within a specific time window. There are no recurring charges, no stored payment methods, no chargebacks, and no disputes. Once the authorization is signed and submitted, it either settles or it does not. This model aligns with how autonomous agents operate: discrete, stateless interactions with deterministic cost.

Open Standard

The x402 protocol specification is public. Anyone can implement a server that returns 402 responses with the correct header format. Anyone can build a client that handles the payment flow. Anyone can operate a facilitator that verifies and settles payments. There is no central authority, no proprietary SDK requirement, and no licensing fee. The protocol specification is maintained at docs.x402.org.

Chain-Agnostic

x402 uses CAIP-2 chain identifiers to specify payment networks. The network field in the Payment-Required header is a CAIP-2 string (e.g., eip155:8453 for Base mainnet, eip155:84532 for Base Sepolia). This allows the protocol to support any EVM chain without modification to the header format or flow logic.

Payment Headers

x402 v2 defines three HTTP headers that carry payment data as base64-encoded JSON:

The base64 encoding in v2 replaced the JSON header encoding used in v1, resolving HTTP header size and parsing issues across proxy layers and CDNs.

The Facilitator Role

A facilitator is a trusted intermediary that sits between the client and server. Its responsibilities include:

• Signature verification. Confirming the EIP-3009 transferWithAuthorization signature is valid and was produced by the claimed payer.
• Balance checking. Verifying that the payer's wallet holds sufficient USDC to cover the payment amount.
• Parameter validation. Ensuring the payment amount, recipient, network, and timeout match the server's advertised requirements.
• On-chain settlement. Submitting the transferWithAuthorization call to the blockchain, paying gas fees, and returning the transaction hash.

The facilitator never takes custody of funds. The EIP-3009 authorization transfers USDC directly from the payer's wallet to the server's payTo address. The facilitator merely executes the pre-authorized transfer.

OpenX402 is the reference facilitator implementation, operated at facilitator.openx402.ai. It supports Base mainnet and Base Sepolia. Any x402 server can specify which facilitator(s) it trusts, and multiple facilitators can coexist — the protocol does not mandate a single facilitator.

Why EIP-3009 transferWithAuthorization

EIP-3009 is a standard for gasless token transfers on ERC-20 tokens that support it. The transferWithAuthorization function allows a token holder to sign an off-chain message authorizing a transfer, which any third party can then submit on-chain.

x402 uses EIP-3009 specifically because:

• No gas required from the payer. The signer does not need ETH or any native gas token. The relayer (facilitator) pays gas.
• Direct transfer. Funds move from payer to recipient in a single atomic operation. There is no intermediate escrow or approval step.
• Nonce-based replay protection. Each authorization includes a unique nonce, preventing double-spending without requiring on-chain nonce management by the payer.
• Time-bounded validity. The validAfter and validBefore fields create a window during which the authorization can be executed, after which it expires automatically.
• EIP-712 typed data signing. The authorization is signed as structured typed data, making it verifiable and human-readable in wallet interfaces.

USDC on both Ethereum mainnet and Base implements EIP-3009, making it the natural payment asset for the protocol.

Why USDC on Base

x402 currently operates primarily on Base (CAIP-2: eip155:8453) using USDC as the payment asset.

Why Base

• Low transaction fees. Base is an Ethereum L2 rollup with gas costs typically under $0.01 per transaction, making micropayments economically viable.
• Fast finality. Transactions confirm in approximately 2 seconds, enabling near-real-time settlement within the HTTP request lifecycle.
• Coinbase ecosystem. Base is built by Coinbase, providing direct fiat on-ramps for agents and users who need to fund wallets with USDC.
• EVM compatibility. Full compatibility with Ethereum tooling, wallets, and smart contracts — no custom integrations required.

Why USDC

• Price stability. As a fiat-backed stablecoin pegged to the U.S. dollar, USDC eliminates exchange rate volatility from API pricing.
• EIP-3009 support. USDC implements transferWithAuthorization, enabling the gasless payment model that x402 depends on. Most ERC-20 tokens do not support this standard.
• Wide availability. USDC is one of the most widely held stablecoins, available on every major exchange and easily bridgeable across chains.
• Six decimal precision. USDC uses 6 decimal places, allowing prices as granular as $0.000001 — sufficient for micropayment use cases.

x402 vs Traditional API Monetization

The fundamental shift is from identity-based access (prove who you are, then consume) to payment-based access (pay for what you consume, identity is irrelevant). This distinction makes x402 particularly suited for autonomous agents, ephemeral processes, and cross-border service consumption.

The x402 Ecosystem

Protocol Specification

The x402 protocol is documented at docs.x402.org. The specification covers header formats, payment schemes, facilitator requirements, and the Bazaar discovery extension for machine-readable service catalogs.

SDKs

Official SDKs handle the client-side payment flow:

Using @x402/fetch, a developer wraps the standard fetch function with a wallet, and all 402 handling becomes transparent:

import { wrapFetchWithPayment } from "@x402/fetch";

const paidFetch = wrapFetchWithPayment(fetch, walletClient);
const response = await paidFetch("https://example.com/api/resource");

Facilitators

Facilitators are the settlement layer. OpenX402 (facilitator.openx402.ai) is the reference implementation. The protocol supports multiple facilitators — servers declare which facilitators they trust, and clients can select among them.

Discovery

The Bazaar extension provides machine-readable resource discovery. Servers expose a /discovery/resources endpoint returning a catalog of all available endpoints, pricing, and payment requirements. The /.well-known/x402 endpoint provides protocol metadata including supported networks and trusted facilitators. These endpoints allow agents to autonomously discover and evaluate x402-compatible services.

Compatible Services

x402 is used by services across categories including telecom APIs (such as Dial for SMS, voice, and OSINT), data providers, compute platforms, and content services. The OpenX402 facilitator maintains a registry of verified x402-compatible services.

Further Reading

• What Is HTTP 402? — The history of the "Payment Required" status code, why it was reserved in 1997, and how x402 finally implements it.
• Crypto Payments for APIs — Why stablecoin micropayments are replacing API keys for autonomous agent access.