# What is an x402 facilitator, and do you need one? A facilitator is the service that checks an x402 payment authorisation is valid and then settles it on-chain. It exposes two endpoints, verify and settle, and it pays the gas. Because it submits the transaction, the on-chain sender is the facilitator rather than the payer, which is what makes x402 payments identifiable afterwards. Published: 2026-10-14 Last reviewed: 2026-10-14 Publisher: Roundhouse AI Ltd. Source: https://roundhouseai.io/resources/what-is-an-x402-facilitator --- ## What does a facilitator actually do? An x402 seller has a problem it did not ask for. To take a payment it would need an RPC endpoint, a funded hot wallet, nonce management, gas estimation, reorg handling and a signature verifier. That is a blockchain team, and the seller only wanted to charge a tenth of a cent for an API call. The facilitator absorbs all of it behind two HTTP endpoints. | Endpoint | Question it answers | Touches the chain? | | --- | --- | --- | | `POST /verify` | Is this authorisation valid, unspent and sufficient? | Reads only | | `POST /settle` | Put it on-chain and tell me the transaction hash | Writes, and pays gas | The seller calls `verify` before doing any work, and `settle` once it has decided to serve the request. Between those two calls it is holding a signed promise, not money. ## Why does the facilitator pay the gas? Because the buyer signed an authorisation rather than a transaction. On EVM chains the buyer produces an [EIP-3009](https://roundhouseai.io/resources/eip-3009-transfer-with-authorization-explained) `TransferWithAuthorization` signature, which is a message, not something that can be broadcast by itself. Somebody has to wrap it in a transaction and pay for the block space. That somebody is the facilitator, and the consequence is the single most useful property of the whole design: **an agent can hold nothing but a stablecoin and still pay.** It never needs ETH, SOL or any native token. For a wallet that an operator funds once and forgets about, removing the second asset removes most of the operational work. [Who pays gas in x402](https://roundhouseai.io/resources/who-pays-gas-in-x402) covers where that cost actually lands. ## Why is the facilitator the thing that makes payments findable? This is the part people miss, and it decides whether the ecosystem can be measured at all. A stablecoin transfer on its own is anonymous in the sense that matters here: nothing in a `Transfer` event says what it was for. An x402 payment looks like any other transfer, except for one thing. Because the facilitator broadcast it, **the transaction's `from` address is the facilitator, not the buyer**. That turns an unidentifiable transfer into an attributable one. If the sender is a known facilitator wallet, the transfer was relayed by a party that only relays x402 payments. If it is not, the transfer is some other gasless transfer and the x402 claim is unestablished. > [!IMPORTANT] > The gasless-transfer marker on its own is not evidence of x402. The same EIP-3009 mechanism predates the protocol and is used by unrelated systems. The relayer identity is the discriminator. [What proves a transfer was an x402 payment](https://roundhouseai.io/resources/what-proves-a-transfer-was-an-x402-payment) is the longer version of this argument. ## Which facilitators exist? The landscape as of October 2026, with the caveat that this moves and the [x402 directory](https://x402.org) is the live list: - **Coinbase CDP.** The most-used facilitator and the default in most tutorials. Reporting in 2026 put it at a large majority of relayed volume, though the precise share differs by source and by whether you count transactions or dollars. - **thirdweb.** A general web3 infrastructure provider with an x402 facilitator alongside its wallet and contract tooling. - **PayAI.** Runs both a facilitator and one of the larger public resource catalogues. - **Cloudflare.** Has published a deferred-payment scheme aimed at very high-frequency micropayments, where settling every call individually is the wrong shape. - **Self-hosted.** The reference implementation is open source and a seller that wants no third party in the path can run its own. [Running your own facilitator](https://roundhouseai.io/docs/guides/use-the-roundhouse-facilitator) is a real option rather than a theoretical one. - **Roundhouse.** Runs a first-party facilitator for sellers who want the settlement and the index to come from the same place. ## What are you trusting a facilitator with? More than the marketing suggests, and it is worth being precise. A facilitator sees every payment authorisation before it is spent. Security work published in 2026 found two classes of problem that follow from that position. In one, a party that observes a signed authorisation can submit it first and consume the nonce, so the legitimate settlement fails. In another, a facilitator whose `verify` does not reserve the nonce lets the same authorisation unlock a resource more than once. Neither is a reason to avoid facilitators. Both are reasons to pick one that documents its replay handling, and to bind payments to a specific resource rather than treating any valid payment as payment for anything. [x402 security](https://roundhouseai.io/docs/x402/receipts-and-verification) goes through the mitigations. The commercial trust is smaller than the technical trust. A facilitator cannot take the money: the authorisation names the payee, and the facilitator cannot change it. What it can do is fail to settle, settle late, or go down. ## Frequently asked questions ### Can a seller skip the facilitator entirely? Yes, by running the verify and settle logic itself. It needs an RPC endpoint and a funded wallet for gas, and it takes on nonce and reorg handling. For a seller already operating on-chain infrastructure this is reasonable. For an API business it usually is not worth it. ### Does the facilitator hold my money at any point? No. On the standard EVM path the authorisation transfers value directly from the buyer to the payee named in the signature. The facilitator submits that transfer and pays the gas. It is never a custodian of the payment. ### What happens if the facilitator goes down mid-request? The seller has a verified authorisation it has not settled. The correct behaviour is to not serve the resource, because an unsettled authorisation is a promise and not a payment. Sellers that serve first and settle later are accepting a small loss rate in exchange for latency. ### Can I use more than one facilitator? Yes. The payment requirements a server advertises can list several accepted terms, and a buyer picks one. Sellers operating across chains commonly use a different facilitator per chain, since facilitator coverage and chain coverage are not the same thing. ### How do I tell which facilitator relayed a given payment? By the transaction sender. Roundhouse attributes each settlement to the operator that relayed it and publishes the result per facilitator at [/facilitators](https://roundhouseai.io/facilitators), including the settlements it could not attribute to any known operator. ## Where to check this yourself The facilitator claims above are checkable rather than taken on faith. [/facilitators](https://roundhouseai.io/facilitators) lists the operators Roundhouse has observed relaying settlements, with the volume attributed to each and the share that remains unattributed. The [data API](https://roundhouseai.io/docs/api) answers the same question programmatically, and [/transactions](https://roundhouseai.io/transactions) lets you filter the raw settlements by route. --- Roundhouse indexes x402 settlements and ERC-8004 identities into one public record. - Every article: https://roundhouseai.io/resources.md - Every surface on this site: https://roundhouseai.io/llms.txt - The index, endpoints and schema: https://api.roundhouseai.io/v0 - A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402 - Limits and the SQL surface: https://roundhouseai.io/docs/api