Roundhouse

Understand x402

Facilitators

Understand what a facilitator does with your signed authorization, and what it cannot do.

Read as markdown

A facilitator takes a signed payment authorization, checks it, and broadcasts it on-chain, paying the gas. It is the only moving part in x402 that is neither the client nor the merchant.

What it does#

Two endpoints, in this order:

http
POST /verify   → is this authorization valid, right now, for these requirements?
POST /settle   → broadcast it, and tell me the transaction hash

/verify is where the real work happens. A correct implementation checks:

  • The signature. ECDSA recovery against the claimed payer, over the token's on-chain EIP-712 domain — with an ERC-1271 fallback for contract wallets.
  • payTo. The authorization's to must equal the resource's payTo. Skipping this is how a payment gets verified for the wrong recipient.
  • The amount against what was required.
  • The validity window (validAfter / validBefore).
  • The nonce, for shape and for replay.
  • The payer's balance, so a settle that cannot land is rejected before it is attempted.

Caution

A facilitator that returns isValid: true after checking only the window and the amount will accept a forged authorization from any address with a garbage signature. This is not hypothetical — it was a real bug in a real implementation, and the fix is 10 regression tests made of the forgeries that used to pass. If you are evaluating a facilitator, ask what its verify path checks.

What it cannot do#

The payer, the payee, the amount and the expiry are all inside the signed authorization. A facilitator can therefore:

  • refuse to settle,
  • delay settling,
  • settle exactly what you signed.

It cannot redirect the funds, change the amount, take an unagreed cut, or settle twice — the token contract enforces the last one via the nonce. This is why "use a facilitator" is not the same kind of trust decision as "use a custodian". The worst a hostile facilitator can do to a payment is fail to make it.

What it can see is your payment metadata: who you are paying, how much, how often. That is a privacy consideration, not a custody one.

The Roundhouse facilitator#

http
GET  https://x402.roundhouse.studio/            service descriptor
GET  https://x402.roundhouse.studio/supported    schemes and networks served
POST https://x402.roundhouse.studio/verify
POST https://x402.roundhouse.studio/settle

Free, no transaction cap, no percentage. It speaks the standard x402 wire format — accepts in the 402 body, X-PAYMENT in, X-PAYMENT-RESPONSE out — so off-the-shelf clients and middleware work unmodified. Currently serving exact with USDC on Base mainnet; check /supported rather than assuming, always.

Roundhouse earns from selling aggregated index access, not from facilitation. Every settlement it handles is indexed, which is the actual exchange: you get free settlement, the record gets a verified row, and your service accumulates the observable history other agents use to decide whether to pay you.

To point your own endpoint at it, see charge for your API.

The facilitator registry#

A facilitator's relayer wallet is the transaction's from address, which is how an indexer attributes a settlement to an operator. Roundhouse keeps a registry of known operators and their relayer addresses — 36 operators across roughly 158 wallets at the time of writing, synced from the open facilitators package (MIT, maintained by Merit Systems / x402scan).

Three details that matter if you consume it:

  • Deprecated addresses are kept. Attribution is historical: a settlement relayed in 2025 keeps its operator even after that operator rotates keys.
  • Operators are grouped, wallets are not. One operator can relay from a pool of addresses. Roundhouse collapses every alias onto one group key, so /facilitators counts per operator rather than per wallet.
  • An unrecognised relayer is stored as its own address, not as "unknown". An address is groupable and can be named later; a null cannot.

Running without one#

You can settle your own payments. An agent that holds the chain's gas token can submit the authorization itself — the index records that as self, "payer-submitted", and it is a perfectly ordinary settlement.

This is possible, and almost nobody does it, because it puts you back in the business of holding two assets and managing gas, which is the problem the facilitator exists to remove.

Next steps#