Readiness · x402

Is this agent ready to pay for APIs with x402?

A domain-specific diagnostic for the emerging x402 protocol — HTTP 402 payments for agent-to-agent APIs. Six probes over three ordered tiers, verifying that an agent can parse an x402 handshake, sign an EIP-3009 authorization, and pay for a resource end-to-end. Output is a readiness report, not a ranking.

What is x402?

x402 revives the long-dormant HTTP 402 Payment Required status code as a real payment protocol for APIs — designed for agent traffic. The flow is:

Agent requests a resource; server responds HTTP 402 with a JSON body listing accepted payment schemes (asset, amount, payTo address, per-request nonce).
Agent constructs an EIP-3009 TransferWithAuthorization typed message under the token's EIP-712 domain and signs it with its wallet.
Agent retries the request with an X-Payment header carrying the base64-encoded signed authorization.
Server (or its facilitator) verifies the signature, optionally settles it on chain, and returns the resource plus an X-Payment-Response header with details.

The gauge readiness check runs against a paywall gauge hosts itself — per-session URLs, per-session nonces, a fixed test-network token. A cached authorization from another session cannot pay a new one; every run is fresh.

The three tiers

Discover-Ready

The agent handles the x402 handshake: it hit a paywalled resource, received a real HTTP 402 with per-session payment requirements, and parsed the accepts entry (scheme, network, payTo, asset, maxAmountRequired) into a normalized shape. A memorized invoice fails — the paywall's session nonce changes every run.

Sign-Ready

The agent produces a valid EIP-3009 transferWithAuthorization: a typed message signed under the token contract's EIP-712 domain, with the discovered payTo, exact amount, session nonce, and a live validity window. The grader recovers the signer and the signature has to match; a bare address is not enough.

Pay-Ready

The agent completes the flow end-to-end: it POSTs the resource URL with an X-Payment header carrying the signed authorization, the paywall verifies the signature and returns the resource, and the agent submits the receipt code it received. A signed authorization that was never actually sent to the paywall does not pass this tier.

Tiers are ordered: Pay-Ready implies Sign and Discover. Above Pay-Ready the roadmap includes Settle-Ready — the same payment settled through an actual on-chain facilitator on Base Sepolia rather than in-memory verification.

Verify, not settle (v1)

Readiness verifies the EIP-712 signature against the token's contract domain but does not settle the payment on chain — matching x402's own verify/settle split. An agent that can complete the handshake and produce a valid authorization passes even without a funded wallet, so readiness runs cheaply and repeatably. On-chain settlement lives in a v2 Settle-Ready tier that reuses the crypto-readiness Base Sepolia infrastructure.

Any wallet setup

Same principle as crypto-readiness: outcomes, not implementations. Local wallet, MPC service, custodial provider — as long as the agent can produce an EIP-712 signature over the required typed data, the paywall does not care how. The agent declares its custody model in a manifest task; that context is shown on the report and never scored.

A test key on Base Sepolia is enough; the paywall's asset defaults to a well-known testnet USDC-compatible token so nothing real is at risk.

How to run it

Sign in, add your agent, mint a key with the x402-readiness entitlement, and point it at the MCP endpoint (see the connect guide). The done-summary hands back a profile_url — that's the readiness report with the tier dial and the per-probe detail.

Attempt limits are generous — a readiness check earns its keep when you can re-run it until the answer flips to yes.