How x402 maps to the payment lifecycle.

How is the service discovered?

x402 uses standard HTTP endpoints as its discovery mechanism. Any URL can become a paid resource — the agent simply sends a standard GET request. Service discovery happens through existing web infrastructure: DNS, links, registries. The Bazaar pattern extends this with a service directory specifically for x402-gated resources.

Unlike protocols that require a specialized discovery phase, x402 piggybacks on HTTP itself. The 402 status code is the discovery signal — the resource declares itself as paid, and the client responds accordingly.

// Standard fetch — the URL IS the discovery
const res = await fetch('https://api.example.com/data');
// Status 402 → this resource requires payment

What are the terms of settlement?

The HTTP 402 response carries a base64-encoded PAYMENT-REQUIRED header containing the complete payment terms: which networks are accepted, what assets, how much, and where to send it. This is machine-readable negotiation — no handshake protocol, no session state, no round trips.

The header contains a structured JSON payload with accepts array, each entry specifying scheme, network, amount, recipient address, and asset contract. The agent picks the cheapest or fastest option and proceeds.

// Decode the payment terms from 402 response
const header = res.headers.get('PAYMENT-REQUIRED');
const terms = JSON.parse(atob(header));
// → { accepts: [{ scheme: "exact", network: "base", amount: "100000",
//      payTo: "0x...", asset: "0x...USDC" }] }

How does the instruction signal travel?

The payment instruction travels as an HTTP header. The agent constructs a PAYMENT-SIGNATURE header containing the signed EIP-3009 authorization and retries the original request. The transport mechanism is HTTP itself — the same channel that carried the price signal carries the payment proof.

// Retry with payment proof in headers
const paid = await fetch(url, {
  headers: { 'PAYMENT-SIGNATURE': signedPayload }
});

Is it cryptographically valid?

Authorization uses EIP-3009 transferWithAuthorization — a gasless signature standard for USDC. The agent signs a typed message authorizing the token transfer without needing ETH for gas. The Cloudflare Worker validates the signature before submitting the transaction on-chain via Coinbase CDP.

// EIP-3009 transferWithAuthorization signature
const sig = await wallet.signTypedData({
  types: { TransferWithAuthorization: [...] },
  primaryType: 'TransferWithAuthorization',
  message: { from, to, value, validAfter, validBefore, nonce }
});

Who clears and routes?

Coinbase Developer Platform (CDP) acts as the facilitator. The Cloudflare Worker submits the signed EIP-3009 authorization to Base L2 via CDP's API. CDP handles gas sponsorship, transaction submission, and confirmation monitoring. The facilitator pattern separates signing (agent) from submission (infrastructure).

// CDP submits the pre-signed authorization on-chain
const tx = await cdp.submitTransfer({
  authorization: signedPayload,
  network: 'base',
  gasSponsored: true
});

Where is the ledger of record?

On-chain finality happens on Base L2, which inherits Ethereum's security through the OP Stack. The USDC transfer is recorded on-chain, providing cryptographic proof of payment that both the agent and the service can independently verify. Base achieves finality in approximately 2 seconds.

// On-chain receipt — verifiable by anyone
// Base L2 → OP Stack → Ethereum L1 security
// Finality: ~2s on Base