What are you taking on?#
A facilitator does two things: verify that a payment authorisation is valid and unspent, and submit it on-chain while paying the gas. The reference implementation is open source, so the code is not the hard part.
The operational surface is.
| Component | What it means in practice |
|---|---|
| An RPC endpoint | A provider relationship, rate limits, and failover when it degrades |
| A funded hot wallet | A key that signs continuously, holding native tokens |
| Nonce management | Serialising submissions so your own transactions do not collide |
| Gas monitoring | Topping up, and repricing when the chain is busy |
| Reorg handling | Settlements that were included and then were not |
| Per-chain everything | All of the above again for each chain you support |
The irony is worth naming. By removing the native-token requirement from your buyers, you have taken it on yourself. The wallet that quietly runs out of gas and fails every payment with all health checks green is now yours.
When is it worth it?#
Three cases, and they are narrower than enthusiasm suggests.
You already operate on-chain infrastructure. If you run RPC endpoints, hot wallets and monitoring for other reasons, the marginal cost is small and you have the operational muscle already.
Fees are material at your volume. Per-transaction facilitator fees are small, so this threshold is high. Work out your annual fee bill before assuming you are above it; most sellers are not.
A third party in the payment path is unacceptable. A facilitator sees every payment authorisation: payer addresses, amounts, resource identifiers. That is a meaningful amount of commercial intelligence about your business flowing to someone else. For some businesses that is a real objection rather than a theoretical one.
When is it not?#
To save money at low volume. The fees are a fraction of a cent. The operational cost is a person paying attention.
For reliability. A self-hosted facilitator that one team maintains is not more reliable than a managed one, and it fails in ways you have not seen before. If uptime is the goal, use two facilitators on two chains rather than running one yourself.
Because the code is open. Available code is not an argument for running it. The question is whether you want the operations.
Warning
The failure you will actually have is the wallet running out of gas. It fails every payment, it looks like a facilitator outage from your logs, and nothing in the x402 path reports it as a funding problem. Alert on the balance, with headroom, before you take any traffic.
What to get right if you do#
Verification must reserve the nonce. Research in 2026 found facilitators where /verify was stateless and did not reserve the payment nonce, while /settle was not atomically bound to a specific verification result, which let a resource be delivered more than once under one authorisation. Bind them.
Check the caller is the authorised facilitator. The settlement preemption finding was that anyone observing an authorisation can submit it first and consume the nonce. Where the token path allows it, settlement should check that the submitter is the facilitator the client authorised.
Serialise your submissions. Your own transactions compete for nonces on your own wallet. Parallel submission without serialisation produces stuck transactions and a queue that never drains.
Handle reorgs. A settlement included in a block that is later reorganised out has not happened. If you report it as settled, your accounting and your buyer's disagree.
The known attacks covers all of these as classes, and a self-hosted facilitator owns every one of them rather than inheriting a fix.
Is there a middle option?#
Run your own and advertise a managed one alongside it.
Your accepts array can carry several entries. Listing both lets you settle most traffic yourself while a client that cannot use your path falls back to a facilitator that is somebody else's problem. You get the economics on the bulk and keep the availability floor.
This costs a second reconciliation and is the shape most sellers who self-host should end up with. Facilitators compared covers what to pick for the fallback.
Frequently asked questions#
Can I self-host on one chain and use a managed facilitator on another?#
Yes, and it is a sensible split. Self-host where your volume justifies it and use a managed facilitator elsewhere rather than taking on a second chain's operations.
Does self-hosting change what buyers see?#
Barely. Your terms name the chain, asset and payee; the facilitator is behind your server. What changes is the relayer address on-chain, which is what settlement indexes attribute from, so your settlements will show as relayed by you rather than by a known operator.
Does that affect my visibility?#
Somewhat. An index grading evidence by relayer identity treats a known facilitator as strong evidence of x402. A first-party facilitator is strongest for the party that operates it and unknown to everyone else, so your settlements may read as unestablished to third parties until your address is recognised.
How much native token do I need?#
Enough for your transaction rate plus headroom for a gas spike, monitored and topped up. On a cheap chain that is a small balance and the operational discipline matters more than the amount.
Can I charge others to use my facilitator?#
That is the facilitator business, and it is a different product from your API with different obligations. Running one for yourself and running one for others are not the same undertaking.
Where to check this yourself#
Use the Roundhouse facilitator documents the managed path, which is the comparison worth making before building. /facilitators shows which operators are relaying settlements and at what share, including the proportion of settlements that cannot be attributed to any recognised operator.