Same x402, multiple chains. No bridge, no account.

Chain status today no testnet flag

Buyer payment: Base, Polygon (USDC EIP-3009), Solana (USDC SPL + Ed25519) — 3 facilitators per chain (external broadcasters plus a local-key fallback). Seller payout: Base, Polygon, Arbitrum One, Optimism, Avalanche C-Chain, Solana — USDC via CCTP to your declared payout_chain. A chain outage is contained — Solana going dark cannot affect Base, and vice-versa. Buyer payments settle on the buyer's chain. Seller payouts are routed cross-chain via CCTP.

Contracts above are USDC issued by Circle — the canonical, audited, redeemable-for-USD versions. We do not accept bridged or wrapped variants on any chain.

How a buyer picks a chain

The 402 response now ships an accepts[] array — one entry per chain the endpoint supports. The buyer picks one and replies with an X-Payment header whose network field matches.

// HTTP/1.1 402 Payment Required — /v1/pdf-md — runtime today
{
  "x402Version": 1,
  "accepts": [
    {"network": "base",      "scheme": "exact",                       "asset": "0x833589…", "maxAmountRequired": "10000";},
    {"network": "base",      "scheme": "transfer-with-authorization", "asset": "0x833589…", "maxAmountRequired": "10000";},
    {"network": "polygon",   "scheme": "exact",                       "asset": "0x3c499c…", "maxAmountRequired": "10000";}
    // solana network entry omitted for brevity — same shape as base/polygon.
  ]
}

Endpoints under sell-side can narrow this list via seller_endpoints.accepted_chains. First-party endpoints default to ["base","polygon","solana"].

Two payment models per chain

Every chain supports exact (buyer broadcasts the transaction and reports the txHash). EVM chains also support transfer-with-authorization (buyer signs an EIP-3009 authorization, a facilitator broadcasts on their behalf — no gas in the buyer's wallet required).

The spl-transfer scheme is the Solana analogue of transfer-with-authorization on EVM: the buyer pre-signs the transaction but does not broadcast it; the facilitator stack pays the gas and broadcasts. Each chain runs a 3-level facilitator stack (external primary → external secondary → local-key fallback), for a total of 9 stacks across Base, Polygon, and Solana. Each buyer payment is covered by the 3 facilitators of its source chain; cross-chain settlement bridges (see next section) deliver the seller's payout on whichever chain they registered to be paid. The legacy exact scheme on Solana (buyer-broadcasts) remains available for clients that prefer paying gas themselves.

Cross-chain settlement layer Live · May 2026

A buyer paying on chain X never has to think about the chain the seller registered on. tools402 collects on the buyer's chain, then bridges the payout to the seller's chain before final settlement — the seller receives USDC on their preferred chain with one HTTP call from the buyer.

The bridge is invoked by the async settle-sellers layer, not the request hot path. The buyer's 402 response time is unaffected by cross-chain settlement — the marketplace acknowledges the payment in <1s, then asynchronously routes to the seller via the bridge. 0 inventory at tools402: Mayan solvers front the destination-chain liquidity and are reimbursed via the bridge protocol itself. No 30k$ hot wallet sitting on each chain.

The cross-chain settlement layer is implemented in src/lib/bridge-client.ts (Mayan wrapper) and src/lib/cross-chain-settle.ts (seller-payout router with wallet-format-based chain inference). All signing happens through the CDP managed TEE — no raw private key on tools402 servers (anti-pattern 1 honored).

Wallets you can verify

Every wallet the marketplace touches is enumerated under /v1/_status and surfaced on the /proof page — counts are runtime, not marketing. Facilitator stacks on Base, Polygon, and Solana each run 3 levels: external broadcasters plus a local-key fallback. Logical recipients: one per chain. The EVM recipient address is HD-derived and shared across EVM payout chains — one key, multiple settlements, no extra custody. Smart-account-internal entries handle sweeps only — labelled automation_internal, never returned as recipient_wallet in any 402 quote.

You do not give us a key. Buyer-side payments land on a self-custody address. Marketplace fees route to the same self-custody addresses. The CDP managed TEE handles only seller payout signing and the 24-hour sweep, both with an allowlist of five contracts and a hard $20 cap.

Per-chain configuration on the seller side

The POST /v1/_seller/register body accepts a per-chain wallets map plus a per-chain signatures map (EIP-712 for EVM chains, Ed25519 / nacl for Solana), and a required payout_chain field. Choose your payout chain (Base, Polygon, Arbitrum, Optimism, Avalanche, or Solana) — paid in USDC there; cross-chain handled via CCTP. 402 quotes accept base, polygon, and solana. Endpoints inherit an accepted_chains column you can narrow at the endpoint level. Settlement to the wallet on your declared payout_chain runs through the cross-chain settlement layer — buyer-chain and seller-chain can differ; CCTP routes the payout with 0 inventory on tools402. Settlement runs daily at 00:00 UTC, in USDC. A balance ≥ 1 USDC is paid at the next run (within 24h). A balance below 1 USDC carries over and accumulates across days until it reaches 1 USDC, then it's paid.

// POST /v1/_seller/register
{
  "primary_wallet": "0x…",
  "wallets": {"base":      "0x…",
    "solana":    "…",
    "polygon":   "0x…",
    "arbitrum":  "0x…",
    "optimism":  "0x…",
    "avalanche": "0x…";},
  "signatures": {"base":      "0x… (EIP-712)",
    "solana":    "…   (Ed25519)",
    "polygon":   "0x… (EIP-712)",
    "arbitrum":  "0x… (EIP-712)",
    "optimism":  "0x… (EIP-712)",
    "avalanche": "0x… (EIP-712)";},
  "payout_chain": "base",
  "slug": "<your-slug>",
  "ts": 1779105600
}

See sell-side docs for the full registration flow and the seller_endpoints column reference.

Audit and receipts

Every paid call receives an Ed25519-signed audit receipt under /v1/_audit/<txHash>. The canonical JSON includes a chain field (CAIP-2: eip155:8453, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp, eip155:137, eip155:42161, eip155:10, eip155:43114) so receipts produced under one chain cannot be replayed against another. Pre-multichain receipts default to eip155:8453 for backward-compat verification.

Try it copy-paste, swap the chain param

One curl, three buyer chains today. Swap the chain query param to pay from whichever chain the buyer's agent holds USDC on. The server replies with a 402 carrying the accepts[] array; the buyer signs and re-sends with an X-PAYMENT header. No SDK install required — copy, paste, ship.

# Buyer-accepted chains today: base | polygon | solana
# Buyer chains: base | polygon | solana
curl -X POST https://api.tools402.dev/v1/ocr?chain=base \
  -H "X-PAYMENT: <eip3009-signature>" \
  -F file=@invoice.pdf

See the full endpoint catalogue for all endpoints and their per-endpoint pricing.