x402: The HTTP Standard That Lets Agents Pay for What They Use

When an AI agent needs to call a service it does not control, something has to handle payment. The agent cannot log in, cannot click a payment link, and cannot wait for an invoice. It has to negotiate and pay within the same HTTP request, with no human in the loop. x402 is the protocol that makes that possible.

The name comes from the long-reserved HTTP payment status code, which existed in the specification for decades but was never formally defined. x402 fills that gap with a concrete payment flow designed for machine-to-machine commerce. If you are building an agent that consumes external services, or building a service that agents consume, this is the protocol you will encounter.

What the handshake looks like

An agent makes a standard HTTP request to a paid endpoint. The server responds with the payment-required status and includes a payload in the header: the amount required, the accepted payment rail (x402 currently targets USDC on Ethereum-compatible chains), and a payment address. The agent reads that header, constructs and signs the transaction, includes the payment proof in a subsequent request header, and retries. The server verifies the proof on-chain and returns the response.

The entire exchange happens in the HTTP layer. No redirect, no OAuth flow, no checkout session. The agent handles every step without any part of the flow requiring a browser or a user action.

The one hard prerequisite on the buyer side: the agent needs a funded wallet. The agent's private key signs the payment transaction. If the wallet is empty or the key is misconfigured, the agent cannot call paid endpoints. That is the only blocker, and it is a real one.

What the market looks like today

The index currently tracks 320,972 measured calls to paid agent endpoints over the last 30 days across 25,522 listed endpoints. Of those, 3,829 have more than one distinct paying buyer. That is 15.0% of the listed paid population.

The caveat travels with that number: this is third-party telemetry from Coinbase, not a direct probe. Payment rails that settle off-chain or through other infrastructure are not captured. The 15.0% is a floor, not the full picture, but it is a measurable floor.

That 15.0% matters more than the call volume. A service can generate thousands of calls by routing its own internal traffic through its own endpoint. Buyer count is what separates a service with external customers from a service calling itself. The 3,829 endpoints with multiple buyers represent where x402 commerce is actually happening versus where it is listed and dormant.

The median asking price across paid endpoints is $0.01 per call. Five implausible prices and 68 free endpoints are excluded from that calculation. The $0.01 figure is a midpoint across a wide distribution, not a target. Simple lookup and classification endpoints sit at the low end. Endpoints doing live data retrieval, multi-step orchestration, or inference against specialized models run higher, sometimes by an order of magnitude.

What this means for builders buying agent services

If your agent calls paid endpoints at any volume, the math is worth running before you commit. At $0.01 per call, a thousand calls is ten dollars. That scales linearly with call volume, and the total endpoint cost is real infrastructure spend once a workflow is running in production at any meaningful rate. Build a cost model before you wire a paid endpoint into anything that will run continuously.

Two things worth doing before you depend on a paid endpoint:

First, check whether the endpoint has multiple buyers. An endpoint with only one buyer, or with call volume but no buyer count available, is harder to evaluate. You cannot tell from volume alone whether it is a service in early adoption or a service running a loop. If the index shows buyer count, use it. If it does not, treat the endpoint as unproven and build a fallback.

Second, call the endpoint before you depend on it. Not a single test call but enough calls with a known input to verify that the response structure stays consistent. Endpoints that drift in their output format break downstream workflows in ways that surface at the worst times. This is knowable before you commit.

What this means for builders selling agent services

x402 solves the payment mechanics, not the adoption problem. The protocol tells buyers how to pay. It does not give them a reason to.

The endpoints with multiple buyers in the current market cluster around narrow, specific tasks: domain-specific data retrieval, entity resolution, specialized classification, document parsing against proprietary schemas. The pattern is consistent. Buyers pay repeatedly for endpoints that do something specific they cannot rebuild in a reasonable amount of time. Broad capability endpoints with ambitious descriptions and inconsistent output structures do not get bought more than once.

The useful pricing frame is the buyer's build cost, not the category median. What you are pricing against is the engineering time required to build an equivalent. If your endpoint is cheaper than a day of engineering work and does the job reliably, the economics favor buying. If a buyer can replicate it in an afternoon, you will lose on price regardless of how the market is priced overall.

On the technical side, x402 requires the endpoint to generate a valid payment-required payload on every unauthenticated request, verify payment proofs before serving responses, and handle edge cases correctly: insufficient payment, expired proofs, replay attempts. Libraries exist for the main server environments. Build on one rather than implementing verification logic yourself; the edge cases in verification are where bugs that cost you money live.

What to watch

The x402 specification is young. The payment rail is narrow, and tooling for key management, payment proof caching, and wallet abstraction is still developing. Builders on both sides should expect the low-level plumbing to keep changing while the core HTTP handshake pattern stabilizes.

The practical constraint for most builders right now is wallet operations: key storage, funding automation, and handling the case where a wallet runs dry mid-workflow. These are solved problems in cryptocurrency infrastructure. They are new problems for most AI engineers, and the wallet failure mode has nothing to do with model quality or prompt design. A workflow that ran correctly for a week fails silently when the wallet balance hits zero.

For a live view of which endpoint categories are active, what price bands look like by capability type, and which services have attracted multiple buyers, the index at agents.traderszone.net pulls from crawl data continuously. Individual endpoints churn faster than any article can track. The shape of the market is measurable, and it updates.