Inside the x402 Facilitator: verify, settle, supported

Every x402 payment ends the same way: a resource server hands a signed payload to a facilitator and asks two questions — is this valid, and did it land on-chain. Three HTTP endpoints answer them. This is a tour of that API, its trust model, and the market of services now implementing it.

Over the last two weeks we dissected the three settlement schemes of x402: exact on EVM via EIP-3009, exact on Solana via partially-signed transactions, upto via Permit2, and batch-settlement for deferred redemption. Each scheme defines what a valid payment looks like. But none of them defines who checks it. That job belongs to a component the specs treat almost as an afterthought and production systems treat as critical infrastructure: the facilitator.

The facilitator API is small — two POST endpoints and one GET — but it is the hinge of the entire protocol. Get it right and a seller accepts stablecoin payments on five networks without touching a single RPC node. Get it wrong and you have delegated your revenue recognition to a third party you never audited. The x402 v2 specification, now maintained under the x402 Foundation, finally pins down the contract precisely. Let's walk it.

The role: outsourced chain access, not outsourced custody

A facilitator, per the spec, is "a service that handles payment verification and blockchain settlement." Resource servers can "delegate blockchain operations to trusted third parties or host the endpoints themselves." The official docs add the load-bearing sentence: the facilitator "does not hold funds or act as a custodian."

That non-custodial property is not a policy promise. It falls out of the scheme designs. In the exact scheme, the client signs an EIP-3009 authorization that hardcodes the recipient and the amount; a facilitator that tampers with either produces an invalid signature and the token contract rejects the transfer. In upto, the Permit2 witness binds the recipient and the facilitator address. The facilitator is a courier with a sealed envelope: it can deliver it, delay it, or drop it — it cannot rewrite what is inside.

What the facilitator does own is chain access. It holds funded gas wallets on every network it supports, submits the transactions, absorbs reorgs and RPC flakiness, and reports back over plain HTTP. The seller's entire blockchain footprint collapses to two JSON calls.

The API surface: two POSTs and a GET

The v2 spec defines exactly three endpoints. Both POST endpoints take the same request body: the protocol version, the payment the client sent, and the requirements the server advertised.

// POST /verify and POST /settle share this request shape
{
  "x402Version": 2,
  "paymentPayload": { /* what the client signed */ },
  "paymentRequirements": { /* what the server demanded */ }
}

The paymentPayload is the object the client transmitted in the PAYMENT-SIGNATURE header (base64-encoded JSON, per the v2 HTTP transport, which renamed v1's X-PAYMENT). It carries x402Version, an accepted field echoing the exact PaymentRequirements the client chose from the server's accepts array, and a scheme-specific payload — the EIP-3009 signature, the partially-signed Solana transaction, the Permit2 permit. The facilitator's first job is to check that accepted and paymentRequirements agree. A mismatch means the client is trying to pay against terms the server never offered.

POST /verify — the free pre-flight

Verification is everything that can be checked without spending gas: signature validity, time windows, amounts, recipient binding, replay status, and on-chain balance reads. The response is deliberately minimal.

// valid
{ "isValid": true, "payer": "0x857b...6b66" }

// invalid
{
  "isValid": false,
  "invalidReason": "insufficient_funds",
  "payer": "0x857b...6b66"
}

Four fields total: isValid (required), invalidReason (omitted when valid), payer (the resolved wallet address), and an optional scheme-specific extra. The payer field matters more than it looks: it is the facilitator doing signature recovery for you. The server learns which address is paying without parsing a single byte of scheme payload — useful for rate limiting, allowlists, and account mapping.

The critical property of /verify is that it is side-effect-free and cheap. A resource server calls it before doing any work: verify, then serve, then settle. If verification fails, the request dies with a fresh 402 and nothing was spent on either side.

POST /settle — where money actually moves

Settlement is the irreversible half. The facilitator broadcasts the transaction, waits for confirmation within the requirement's maxTimeoutSeconds, and reports the outcome.

{
  "success": true,
  "payer": "0x857b...6b66",
  "transaction": "0x1234...cdef",
  "network": "eip155:84532"
}

The SettleResponse schema has two required fields beyond success: transaction (the hash, or an empty string on failure) and network in CAIP-2 form. Two optional fields carry the newer schemes. amount — "the actual amount settled in atomic units" — exists because of upto: the authorization ceiling and the settled amount diverge by design, and the server needs the real number for its books. extensions carries protocol-extension data, the channel that batch-settlement and discovery metadata ride on. On failure, errorReason replaces the hash and the server decides whether to retry, re-verify, or void the request.

The server relays this object back to the client base64-encoded in the PAYMENT-RESPONSE header. That closes the loop: the client now holds a facilitator-attested receipt naming the transaction hash it can independently confirm on-chain.

GET /supported — capability discovery

The least discussed endpoint is the one that makes multi-scheme, multi-chain x402 workable. /supported returns three things:

{
  "kinds": [
    { "x402Version": 2, "scheme": "exact", "network": "eip155:84532" }
  ],
  "extensions": [],
  "signers": {
    "eip155:*": ["0x1234...5678"],
    "solana:*": ["CKPK...WYp5"]
  }
}

The kinds array is the facilitator's menu: every (version, scheme, network) triple it can verify and settle. A resource server should intersect this menu with its own preferences before advertising an accepts array to clients — offering a payment kind your facilitator cannot settle is a self-inflicted outage.

The signers map — CAIP-2 patterns to public addresses — is quietly important for security. On Solana, the exact SVM scheme requires the client to build a transaction whose fee payer is the facilitator's key, named in extra.feePayer. The signers list is how anyone can check that the key they are trusting as fee payer actually belongs to the facilitator, rather than an attacker who slipped their own address into a 402 response. Publishing signer sets also lets sellers pin facilitator identities over time.

The error taxonomy is namespaced by scheme

The v2 spec enumerates the values that can appear in invalidReason and errorReason. A few are generic: insufficient_funds, invalid_scheme, unsupported_scheme, invalid_network, invalid_payload, invalid_payment_requirements, invalid_x402_version, invalid_transaction_state, and the catch-alls unexpected_verify_error and unexpected_settle_error.

The rest are namespaced per scheme, in the pattern we first saw in the EIP-3009 deep dive: invalid_exact_evm_payload_authorization_valid_after, invalid_exact_evm_payload_authorization_valid_before, invalid_exact_evm_payload_authorization_value_mismatch, invalid_exact_evm_payload_signature, invalid_exact_evm_payload_recipient_mismatch. Each one maps to a specific invariant of the scheme — time window, amount, signature, recipient binding. For an operator, this taxonomy is your alerting dictionary. A spike in _signature errors means broken client tooling. A spike in insufficient_funds means your buyers' agent wallets are draining faster than their top-ups. A spike in invalid_transaction_state points at replay attempts or races between concurrent settlements.

What a facilitator can and cannot do to you

The trust model deserves precision, because "non-custodial" gets waved around as if it meant "trustless." It does not.

What a facilitator cannot do: steal or redirect funds. The client's signature binds recipient, amount (or amount ceiling), and validity window. Token contracts enforce those bindings on-chain regardless of who submits the transaction.

What a facilitator can do: refuse to settle, settle late, and see everything. Censorship and latency are real levers — the facilitator controls transaction submission, so it controls when and whether your revenue confirms. And it observes the full metadata stream: which buyers pay which sellers, how often, for how much. For an agent economy, that is a complete commercial graph.

This is the same structural argument we made about x402 Bazaar's centralization risk: the protocol is open, but the operational chokepoints concentrate. The facilitator is the biggest chokepoint of all.

The facilitator market, July 2026

The good news is that the market stopped being a monoculture. The official facilitators directory now lists a dozen production options: Coinbase's CDP facilitator; Corbits and Dexter covering EVM plus Solana; Mogami on Base; PayAI multi-network; Polygon's own facilitator for Polygon mainnet and Amoy; Solvador spanning EVM, Solana and NEAR; T54 on the XRP Ledger; and a Stellar facilitator built on the OpenZeppelin Relayer. The public x402.org facilitator remains explicitly a development and testnet service, not a production default.

The reference commercial offering is CDP's facilitator: Base, Polygon, Arbitrum, World and Solana, settling EIP-3009 tokens like USDC and EURC natively and any ERC-20 via Permit2, with 1,000 transactions per month free and $0.001 per transaction after that. At micropayment scale that fee is not decoration: on a one-cent API call, a tenth of a cent of settlement fee is a 10% take rate. On a one-dollar call it is noise. Facilitator pricing quietly determines the minimum viable price of a machine-to-machine API.

The self-host path also matured. x402-rs is an open-source Rust implementation of the full facilitator role that you can run on your own infrastructure; its hosted instance at facilitator.x402.rs exposes a dozen testnets, from Base Sepolia and Polygon Amoy to Solana Devnet, as a free public sandbox. Between hosted-with-fees and self-hosted-with-ops, the decision is the classic one: below serious volume, rent; above it, or when the metadata graph itself is sensitive, own.

What it means for LLM4Agents

LLM4Agents sits on the resource-server side of this API. Our reserve → proxy → settle pipeline is structurally the facilitator flow with an inference call in the middle: verify the payment authorization, do the metered work, settle for what was consumed. That makes the facilitator the single external dependency our x402 revenue path cannot function without.

What it enables: network breadth without chain ops. Supporting Solana and Polygon settlement alongside Base costs us an entry in a config file, not three RPC estates, because the facilitator's /supported menu is the integration surface. The amount field in SettleResponse is exactly what our metered upto billing needs to reconcile authorized ceilings against real usage.

What it threatens: concentration and margin. A single hosted facilitator is a single point of censorship, a single fee schedule applied to every settlement we make, and a single observer of our entire buyer-seller graph. And a facilitator's false success — through bug or compromise — becomes uncollected revenue on our books unless we independently confirm hashes.

Staying on the frontier

Concrete steps, in order. First, abstract the facilitator behind an internal interface keyed on the /supported contract, and integrate a second production facilitator with automatic failover — the same discipline we apply to model fallback chains applied one layer down the stack. Second, add async settlement verification: sample /settle responses and confirm the returned transaction hashes against independent RPCs, alerting on divergence. Third, stand up a self-hosted x402-rs instance against testnets now, so the operational playbook exists before volume economics force the migration. Fourth, poll /supported from our facilitators on a schedule and treat new (scheme, network) kinds as product triggers — upto and batch-settlement support will arrive facilitator by facilitator, and the platforms that enable them first will set prices in those niches. Fifth, wire the error taxonomy into billing observability as first-class metrics, per-reason, per-scheme.

The facilitator API is three endpoints and maybe two pages of spec. It is also the place where the open protocol meets operational reality. Read the spec once; audit your facilitator forever.