# Facilitators

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

Section: Understand x402
Source: https://www.roundhouse.studio/docs/x402/facilitators

---

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](https://www.roundhouse.studio/docs/guides/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`](https://www.npmjs.com/package/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`](https://www.roundhouse.studio/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

- [Receipts and verification](https://www.roundhouse.studio/docs/x402/receipts-and-verification)
- [Errors](https://www.roundhouse.studio/docs/x402/errors) — reading a failure by stage
- [Facilitators on Roundhouse](https://www.roundhouse.studio/facilitators) — who is actually routing volume

---

Every page in these docs is available as markdown at its own URL plus `.md`.
Full index: https://www.roundhouse.studio/docs.md