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

Chain status today no testnet flag

Buyer-accepted today: Base, Polygon (USDC EIP-3009). Buyer shipping this wave: Solana (USDC SPL + Ed25519). Settlement infrastructure only (reported by /v1/_health, not yet returned in 402 accepts[]): Arbitrum One, Optimism, Avalanche C-Chain. Each facilitator stack runs multiple levels (external broadcasters plus a local-key fallback). A chain outage is contained — Solana going dark cannot affect Base, and vice-versa. The marketplace never bridges or swaps; it matches buyers and sellers on the same chain.

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 shipping this wave; arbitrum/optimism/avalanche are settlement-infra only today (see /v1/_health).
  ]
}

Endpoints under sell-side can narrow this list via seller_endpoints.accepted_chains. First-party endpoints default to ["base","polygon","solana"]. Tier 2 EVM chains will be added to the buyer-side accepts[] after explicit seller demand; today they remain settlement-infrastructure only.

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 Wave SOL.3

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 per chain (Base, Polygon, and Solana) each run multiple priority levels: external broadcasters plus a local-key fallback. Tier 2 EVM chains (Arbitrum, Optimism, Avalanche) share the EVM stack via HD-derived key reuse on the settlement side. Logical recipients: one per chain. The EVM recipient address is HD-derived and shared across the EVM chains the marketplace settles on — 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). The protocol shape supports every chain listed below; the buyer-side runtime accepts base, polygon, and solana in 402 quotes. Tier 2 EVM chains remain settlement infrastructure until explicit seller demand opens them buyer-side. Endpoints inherit an accepted_chains column you can narrow at the endpoint level. Settlement to the seller's registered wallet runs through the cross-chain settlement layer (Wave SOL.3) — the buyer-chain and seller-chain can differ, and the bridge handles the rebalancing atomically with 0 inventory on tools402.

// 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)"
  },
  "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, two chains today (Solana joining this wave). 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 ships this wave (SOL.x). Tier 2 EVM chains are settlement infra only.
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.

Roadmap

Tier-2 EVM chains (Arbitrum, Optimism, Avalanche) shipped 2026-05-18 as settlement infrastructure — they appear in /v1/_health but the buyer-side runtime does not return them in 402 accepts[] yet. They will be opened buyer-side after explicit seller demand. Solana buyer-side is shipping in the current wave (SOL.x). Sui, XRPL, and Stellar are gated behind explicit seller demand.