How does the x402 response-settle-retry cycle work?

Every x402 exchange is a three-leg cycle at the same URL. First the client calls the paid endpoint with no payment header and the server responds HTTP 402 with a JSON body whose accepts array lists each acceptable payment option. Then the client picks one of the offers, signs the scheme's message, and retries with an X-PAYMENT header carrying the base64-encoded payload. Finally the server passes that payload to a facilitator, which submits the on-chain settlement to the payTo address, and the server returns the content with HTTP 200 plus an X-PAYMENT-RESPONSE header carrying the settlement transaction hash.

What payment schemes does x402 use?

Two production schemes ride on standard Ethereum signatures that an on-chain client's signing stack already knows how to produce. The default on EVM chains is exact_evm, where the client signs an EIP-3009 transferWithAuthorization message naming the token contract (typically USDC), the payTo address, the exact amount, a validity window, and a nonce. The permit2-exact scheme is the Permit2-signature variant, where the client signs a Permit2 message and settlement routes through Uniswap's Permit2 contract. Both resolve to the same thing from the server's point of view — a verified on-chain settlement at the agreed amount, token, and address.

How does Agent Zero use x402?

Agent Zero sits on both sides of the x402 pattern. On the sell side, its paid intel catalog quotes exact_evm offers in USDC on Base. On the buy side, it uses the same signed-authorization pattern on the client side as the servers it sells to — the same wallet, the same signature primitive, and the same facilitator paths cover both roles.

x402 explained — Onchain Agent Intel (HTTP 402 Payment Required for agentic commerce, Base, Ethereum)

Q: What is x402?

x402 is an open protocol that revives HTTP's long-dormant 402 Payment Required status code and uses it to let clients and servers transact per-request with no human in the loop. A server offers a paid endpoint, a client calls it, the server replies 402 with a machine-readable list of payment options, the client signs one and retries, and the server verifies, settles on-chain through a facilitator, and returns the content — no API key, no OAuth dance, no monthly invoice.

What x402 is

x402 is an open protocol that revives HTTP's long-dormant 402 Payment Required status code and uses it to let clients and servers transact per-request without a human in the loop. A server offers a paid endpoint; a client calls it; the server replies 402 with a machine-readable list of payment options; the client signs one and retries; the server verifies, settles on-chain through a facilitator, and returns the content. There is no API key, no OAuth dance, and no monthly invoice — the payment is carried in a single HTTP header on the retry.

The thing that makes x402 interesting for agents is that every step is wire-level: the offer is a JSON object the client can parse, the signature is an EIP-712 structured data signature the agent's wallet already knows how to produce, and the settlement is a plain on-chain transfer. An autonomous agent can discover, price, pay for, and consume an API in a single round trip without a developer account, which is why x402 has become the de-facto payment layer for agentic commerce on Base and Ethereum.

The response-settle-retry cycle

Every x402 exchange is a three-leg cycle. The second and third legs sit entirely inside two HTTP requests to the same URL — the only difference between them is the signed payment header on the retry.

Initial request. The client calls the paid endpoint with no payment header. The server inspects the request, decides which offer applies, and responds with HTTP 402 Payment Required. The response body is a JSON object whose accepts array lists one entry per acceptable payment option — each entry carries a scheme, a network, a payTo address, an asset (token contract), a maxAmountRequired, and the scheme-specific extra fields the client needs to produce a valid signature.
Signed payment payload on retry. The client picks one of the offers, builds the scheme's signed message with its wallet, base64-encodes the payload, and resends the request with an X-PAYMENT header carrying the payload. The payload is a signed intent — not a broadcast transaction — so the client doesn't need to hold gas on the destination chain to send it.
Facilitator settlement + 200. The server passes the signed payload to a facilitator (see below), the facilitator submits the on-chain settlement call that moves funds to the payTo address, and the server returns the content with HTTP 200. The response carries an X-PAYMENT-RESPONSE header with the settlement transaction hash so the client can verify the receipt against the chain.

The retry is the whole flow — one URL, two requests, one settled on-chain transfer. For an agent that is already holding USDC on Base, "pay for an API call" is a single local signing operation plus two HTTP round trips.

Payment schemes

A scheme is x402's name for the recipe that turns a client's signature into an on-chain settlement. Two schemes are in production today, and both ride on standard Ethereum signatures the agent's wallet already knows how to produce.

`exact_evm`

The exact_evm scheme is the default production scheme on EVM chains. The client signs an EIP-3009 transferWithAuthorization message naming the token contract (typically USDC), the payTo address, the exact amount, a validity window, and a random nonce. The server — via the facilitator — submits that signed authorization to the token contract, which executes the transfer on the agent's behalf. The agent never broadcasts a transaction itself; the facilitator pays the gas.

Agent Zero's paid /v1/intel/* endpoints all quote exact_evm offers in USDC on Base, with the payment destination set to the Agent Zero Safe at 0xaCd134d2AAd0b868EDb395F7d151864188caaF1a. Live offers are in agent.json; per-endpoint prices and the full payment_options arrays are on that manifest, not here.

`permit2-exact`

The permit2-exact scheme is the Permit2-signature variant: the client signs a Permit2 message rather than an EIP-3009 one, letting a single Permit2 approval cover transfers across many tokens. The on-chain settlement call lands at Uniswap's Permit2 contract and routes the transfer from there. It's useful when the agent's wallet already holds a Permit2 approval and the agent is paying across multiple tokens in quick succession.

Both schemes resolve to the same thing from the server's point of view — a verified on-chain settlement at the agreed amount, in the agreed token, to the agreed address — so a paid endpoint can quote both and let the client pick.

Facilitators

A facilitator is the service that takes the client's signed payment payload, verifies it, and submits the matching settlement call on-chain. It sits between the paid endpoint and the chain: the server never touches a private key, and the client never broadcasts a transaction. Two facilitator paths are in production today.

Coinbase CDP facilitator

The Coinbase CDP (Coinbase Developer Platform) facilitator is the reference facilitator from the x402 reference implementation. It exposes a /verify and a /settle endpoint; the paid server calls /verify before serving the response and /settle to submit the on-chain transfer, then returns the settlement tx hash to the client in the response header.

Alchemy MPP gateway

The Alchemy MPP (Metered Payment Protocol) gateway is the second production facilitator surface. MPP wraps the same response-settle-retry pattern but adds wallet-based authentication (SIWE on Ethereum, SIWS on Solana) and supports both USDC-via-x402 and card-funded settlement through the gateway, which lets a server quote the same price in multiple funding paths.

The scanner that powers Agent Zero's indexer picks up x402-enabled endpoints across both facilitator paths. The scan cadence is roughly every 30 seconds for new offers — see /data for the current indexed catalog and /v1/public/stats for live coverage figures.

Chain scope

x402 is chain-neutral in principle — any chain with a stablecoin and an EIP-712-signing wallet can host an offer — but the production surface is overwhelmingly on two chains today: Base and Ethereum. Those are the chains Onchain Agent Intel scans and reports on, and the chains Agent Zero accepts payment on.

On Base, the production asset is USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 — the native Base USDC that EIP-3009 authorizations settle against. Base is where the overwhelming majority of production x402 traffic lands today, because block times and settlement cost favor per-request payment flows. Ethereum mainnet carries the same pattern with mainnet USDC and is live for buyers who need to settle on L1.

BNB Chain is not part of the current scanned-and-reported surface. Payment-side code paths for BNB are retained in the codebase, and historical BNB rows remain on the four-chain census dataset for reproducibility, but no new BNB rows have accrued since 2026-07-28. For a live catalog of x402-paywalled endpoints the indexer has observed on Base and Ethereum, see /data and the agent.json catalog.

How agents discover x402-enabled APIs

A client can't pay what it can't find. x402 discovery surfaces fall into three groups, and a serious agent uses more than one.

Facilitator-side bazaars. The reference CDP facilitator exposes a /discovery/resources endpoint that lists every endpoint the facilitator has observed. A client that already uses the facilitator for settlement gets a native catalog for free.
Directory indexers. Independent indexers such as x402scan.com, x402-list, and B402 publish periodically-refreshed catalogs of x402-enabled endpoints across the ecosystem. They are useful for coverage breadth; verifying that a listed offer still resolves is the client's job before paying.
MCP tools. Agents that speak the Model Context Protocol can discover x402-paywalled endpoints through MCP tool calls. Agent Zero's free, read-only MCP server at https://api.onchainagentintel.io/mcp surfaces the paid /v1/intel/* catalog so an MCP client can see what's available before deciding to pay for a full lookup.

In every case the agent's authoritative lookup is the card at the endpoint host — the facilitator catalog and the directory indexers can go stale between refreshes; the agent.json served live by Agent Zero cannot.

Buyer and seller

Agent Zero sits on both sides of the x402 pattern. It sells its intel over x402 — the paid /v1/intel/* catalog on agent.json is the main surface, and the subscriber portal exposes the human-side equivalent for buyers that prefer a monthly plan. It also buys inputs over x402 — pricing feeds, enrichment lookups, and other agentic data sources — using the same signed-authorization pattern on the client side as the servers it sells to.

That symmetry is why x402 scales for agentic commerce without a centralized clearinghouse: every participant is both a potential buyer and a potential seller, and the same wallet, the same signature primitive, and the same facilitator paths cover both roles.

x402 explained