What Is x402?

Why x402 exists

For most of the internet's history, paying for an API call required infrastructure that did not match the call. You needed an account. You needed a credit card on file. You needed a checkout flow, often a redirect, often a cookie. The minimum viable transaction was a dollar or so, because the overhead of getting paid was a fixed cost that swallowed anything smaller.

That model breaks the moment AI agents start transacting with each other.

Agents do not have credit cards. Agents do not fill out checkout forms. Agents do not have merchant accounts. Agents make decisions in milliseconds, want to pay sub-cent amounts, and do not necessarily know which other agent or service they will pay until the moment they decide to. The legacy payment stack was built for humans with monthly billing cycles. Machine commerce needs a different shape entirely.

x402 is the answer Coinbase and Cloudflare published in 2025 and that the Linux Foundation took over in 2026. The idea is simple. Repurpose an HTTP status code that has been reserved since 1989 and never used. Use it to mean exactly what it says: payment required. Build a protocol around it that lets a server quote a price, lets a client pay, and lets the whole exchange complete in two round trips with no human in the loop.

What x402 specifies

The protocol covers four things. The first three are mechanical. The fourth is what makes the whole thing work in production.

The 402 response shape

When a client requests a resource that costs money, the server responds with HTTP 402 Payment Required. The response body includes structured payment instructions: which network to settle on (Base, Solana, Ethereum, or others), which token (typically USDC), which destination address, and how much. The client reads these instructions, signs a payment, and retries the request.

The payment payload

The retry request includes the signed payment payload as a header. The server (or a facilitator service it delegates to) verifies the payment against the original instructions and the on-chain state. If verified, the server fulfills the original request and returns the resource. If not verified, it returns 402 again with an error.

The facilitator role

Most servers do not want to verify and settle on-chain payments themselves. The facilitator pattern lets a server delegate that work to a third party that specializes in it. Coinbase runs a facilitator. Polymer Labs runs one. Anyspend, PayAI Network, Meridian, and others run them as well. The facilitator is the boring critical infrastructure piece. Without it, every server has to be a payment processor.

Service discovery

The fourth piece is the part that took the longest to converge. Once thousands of services accept x402 payments, the question becomes: how does a client know what is callable and at what price? The Bazaar (Coinbase's discovery layer) and x402scan (the open ecosystem viewer) emerged to answer this. A client can query a directory of x402-enabled endpoints, filter by capability, and decide what to call before paying. Treebeard sits adjacent to this layer: it answers which endpoints to trust, not just which ones exist.

How a payment actually works

Concrete walkthrough. An AI agent wants market data for the next 10 seconds.

1. Agent A sends GET /price/btc to a market-data service.
2. The service responds with 402 Payment Required and instructions: pay 100 micro-USDC to 0xABC... on Base.
3. Agent A signs a USDC transfer for 100 micro-USDC and gets a receipt.
4. Agent A retries the request with X-Payment header containing the signed receipt.
5. The market-data service's facilitator verifies the receipt, confirms settlement, and returns the BTC price.

Total elapsed time, in production: roughly 200 milliseconds. Total transaction cost, including gas: well under a cent. The agent did not have an account, the service did not have a merchant agreement, and no human filled out a form. The whole thing happens between two pieces of software that have never met.

The x402 Foundation

x402 launched as a Coinbase plus Cloudflare project in 2025. By early 2026 the protocol had enough adoption that keeping it inside any single company felt wrong. On April 2, 2026 (the founders called it "402 Day"), the x402 Foundation launched under the Linux Foundation as a neutral steward.

Founding and joining members as of April 2026: Coinbase, Cloudflare, Stripe, Visa, Mastercard, Google, Microsoft, Amazon, Shopify, plus more than a dozen others. The foundation maintains the specification, the reference implementations, and the ecosystem documentation. It does not run a facilitator or a discovery service. It is the standards body, not a product.

Treebeard joined the foundation as an industry member. Our role inside x402 is to handle the trust leg of agent commerce. We do not run a facilitator. We do not run a payment endpoint. We rate the agents that run them.

How it compares to Stripe and Visa

The most common confusion: if Visa joined the x402 Foundation, isn't x402 redundant with Visa?

No. Visa, Stripe, and the rest of the legacy payment stack work for human commerce. They require merchant accounts, KYC, frontend checkout flows, and minimum transaction amounts that price out machine-scale payments. Stripe joined x402 because x402 covers a flow Stripe does not (yet) serve well: machine-to-machine payments at sub-cent granularity, with no merchant onboarding, no chargeback window, and no human in the loop.

The two are complementary, not competitive. Card rails for human commerce. x402 for machine commerce. The same agent will likely use both depending on what it's buying. A consumer-facing AI agent buying movie tickets on a user's behalf uses Visa. The same agent paying for the GPU time it needs to recommend the movie uses x402.

Why x402 needs a trust layer

x402 solves the payment problem. It does not solve the question that comes immediately before payment: should I be paying this counterparty in the first place?

When Agent A receives a 402 response from Service B, Agent A has a choice. Pay 100 micro-USDC and trust the response. Or refuse and look elsewhere. The decision has to happen in milliseconds. Service B might be legitimate. It might also be an audit-laundered shell that passed a security review three months ago and has since been rebuilt to drain payments without delivering anything.

Without a trust signal at the same speed as the payment, x402 commerce defaults to either (a) trust everyone and absorb fraud, or (b) only call counterparties from a small allow-list. Neither scales. The first is expensive. The second prevents the open ecosystem the protocol is designed to enable.

Treebeard's methodology exists to fill that gap. The agent rating, queryable at the same handshake-time latency as the 402 response, tells Agent A whether Service B has the kind of operational signals that justify trusting the payment. The on-chain trust oracle planned for Q3 makes this query a single contract call. Same chain, same block, same speed.

Payment without trust is exposure. x402 plus a continuous trust layer is the production-ready agent commerce stack.

FAQ

Sources

• x402: HTTP-native payment protocol. Reference implementation and specification.
• Linux Foundation. Stewards the x402 Foundation as of April 2, 2026.
• x402.org. Foundation site, member list, and ecosystem documentation.
• Treebeard Methodology. The seven-category trust framework that complements x402 at handshake time.
• How to Evaluate Whether an AI Agent Is Trustworthy. Framework for the trust leg of agent commerce.
• What Is ERC-8004. The identity layer that x402 payments often resolve against.
• Treebeard Agent Directory. Includes filter for x402-enabled agents.