The HTTP status code 402 Payment Required has been reserved since 1996 and ignored for almost thirty years. In 2025, Coinbase finally shipped a working protocol on top of it. x402 is the open standard that lets any HTTP request carry a stablecoin payment, so an AI agent can call an API, pay a few cents in USDC, and receive the response without ever signing up, creating a key, or touching a credit card.

This article walks through the x402 protocol in detail: the 402 handshake, the payment header, USDC settlement on Base, and resource delivery. It then shows why x402 reshapes API monetization for autonomous agents, and how Eco Routes extends x402 beyond a single chain so that an agent holding USDC on Optimism can call an x402 endpoint that settles on Base, with no manual bridging.

When Tim Berners-Lee and the early IETF drafted HTTP/1.1, they left room for digital cash. Status code 402 Payment Required was explicitly "reserved for future use" in the RFC 7231 specification. At the time, there was no settlement rail fast, cheap, or programmable enough to make per-request payments practical. PayPal, Stripe, and card networks all route around HTTP; they sit above it as application-layer workflows, not as native transport primitives.

Stablecoins changed the math. A USDC transfer on Base costs a fraction of a cent and settles in under two seconds. That brings the unit economics of an HTTP request and a payment into the same order of magnitude for the first time. Coinbase's x402 launch, documented on the Coinbase engineering blog, is the protocol layer that finally makes the 402 response code useful.

x402 is a request-response handshake between a client (typically an agent or browser) and a resource server (an API endpoint). The full flow takes one or two round-trips depending on caching. Here is the canonical sequence.

The client sends a normal HTTP request to a protected resource, for example GET /v1/summarize?url=.... The server checks for a payment header. If none is present, it returns a 402 Payment Required response with a JSON body describing what payment it expects.

The 402 body specifies the chain (for example eip155:8453 for Base), the token contract (USDC), the amount in atomic units, the recipient address, a unique nonce, and an expiration timestamp. This payload, standardized in the x402 reference repo on GitHub, is called a payment requirement.

The client constructs an EIP-3009 authorizeTransfer message — a gasless transfer authorization that USDC has supported for years. The agent signs it with the private key of its wallet. No onchain transaction has been broadcast yet. The signature is just bytes.

This is the crucial detail that makes x402 feasible for agents: the client pays zero gas. The server (or a facilitator) will submit the transfer later. The agent only needs to sign, not to hold ETH for gas.

The client replays the same HTTP request, this time including an X-PAYMENT header containing the base64-encoded signed authorization. The server validates the signature and amount against the requirement it sent in step 1.

If validation passes, the server submits the EIP-3009 authorization to the USDC contract through a facilitator — often hosted by Coinbase's Commerce team — which handles the onchain transaction and gas. Settlement lands on Base in under two seconds. The server then returns the actual resource (200 OK with the API response) along with an X-PAYMENT-RESPONSE header confirming the settlement transaction hash.

From the agent's perspective, the entire interaction looks like a slightly delayed HTTP request. From the server's perspective, it collected a pay-per-call micropayment with no invoicing, no API keys, no subscription management, and no chargeback risk.

Traditional API monetization assumes a human developer signs up, enters a credit card, receives an API key, and is billed monthly. That workflow breaks when the caller is an autonomous agent spun up on demand, possibly for a single task lasting minutes. Agents need three things APIs have never provided cleanly:

x402 satisfies all three. The 402 response body is structured JSON the agent can parse. Pricing is declared per-endpoint, and settlement is atomic with resource delivery. This is the foundation for what's starting to be called machine-speed commerce, where pricing, payment, and fulfillment collapse into a single round-trip.

The economic implication is significant. API providers can now sell individual inference calls, database queries, data rows, or compute seconds without building a billing stack. A small tool with a niche audience — a specialized vector search index, a proprietary dataset — can monetize at the per-request level without needing a self-serve portal.

x402 as shipped settles on a single chain per endpoint. Most early deployments settle in USDC on Base, because that's where Coinbase's facilitator runs and where gas is cheapest. That's fine if your agent already holds USDC on Base. It's a problem if your agent lives on Optimism, Arbitrum, Solana, or any of the other chains where real stablecoin balances sit.

Agents don't choose their home chain. They inherit it from whatever wallet, custodian, or framework spawned them. An agent built on top of a Solana-native runtime may end up needing to pay an x402 endpoint that only accepts USDC on Base. Asking the agent to manually bridge is not a solution — bridging introduces minutes of latency, slippage, and failure modes the agent cannot reason about in real time.

This is exactly the problem intent-based routing protocols were designed to solve. Eco Routes in particular treats the agent's starting balance on one chain and the endpoint's settlement chain as an intent pair: "debit this USDC on Optimism, credit this USDC on Base, within N seconds, at a known price." Solvers compete to fulfill the intent, and the agent sees an atomic outcome instead of a multi-step bridging flow.

Here's the pattern for an agent on Optimism calling an x402 endpoint that settles on Base. The agent performs two logical operations that look like a single action from its perspective.

The effect is that x402 becomes chain-agnostic. An endpoint owner picks whatever settlement chain is cheapest and fastest — usually Base — and any agent on any supported chain can pay it without the endpoint operator ever integrating a bridge or a router. The routing layer lives under the agent's wallet, not under the endpoint.

For context on how intent submission looks at the API level, Eco's stablecoin treasury API surface exposes the same primitives agents use for treasury rebalancing — the cross-chain x402 flow is a specialization of the same intent pattern.

It's worth being precise about what the protocol handles and what it leaves to higher layers. x402 is not an identity standard: it does not say who the agent is, only that a payment was made. Identity for agents is being addressed by parallel standards like ERC-8004 for trustless agent registries, which complement x402 but don't overlap with it.

x402 is also not a discovery protocol. There's no registry of x402 endpoints yet; agents must already know the URL they want to call, or discover it through a separate channel. Expect the ecosystem to fill this in over the next twelve months with specialized search and directory services.

Finally, x402 is not opinionated about the token. The reference implementation uses USDC because that's where Coinbase's facilitator is strongest, but the spec allows any ERC-20 with an EIP-3009 authorization surface. That includes USDC, USDT, and the growing set of programmable stablecoins that support gasless transfer primitives.

If you're thinking about putting an x402 paywall in front of an API, a few things to plan for:

x402 is an open protocol that uses HTTP status code 402 Payment Required to request a stablecoin payment from the client. The client signs a gasless EIP-3009 transfer authorization, the server settles it through a facilitator (typically in USDC on Base), and the resource is returned. It enables pay-per-call API access without API keys or accounts.

No. The signing step is gasless because EIP-3009 authorizations are submitted onchain by the server's facilitator, not the client. The agent only needs a USDC balance on the settlement chain. For agents on other chains, a routing layer like an intent settlement layer handles the cross-chain mechanics without requiring the agent to hold gas anywhere specific.

The reference implementation uses USDC on Base, but the protocol is token-agnostic. Any ERC-20 that implements EIP-3009 authorized transfers is compatible. Early deployments may add USDT, USDC.e, and other programmable stablecoins as facilitators expand their supported pools.

Yes, through a cross-chain intent routing layer. The agent submits an intent specifying "debit USDC on Solana, credit the x402 recipient on Base," solvers fulfill it atomically, and the endpoint receives payment on its preferred chain. Eco Routes handles this pattern across fifteen supported chains including Solana.

API keys tie usage to an account, require signup and billing infrastructure, and carry chargeback risk. x402 replaces all of that with a per-request stablecoin payment. There is no account, no monthly invoice, and no dispute process — settlement is final at the protocol layer. It suits agents and short-lived workloads far better than key-based access.