Farcaster vs MCPay
MCPay is the closest thing to us that exists.
It is a live, Apache-2.0, self-hostable x402 payment layer for MCP servers — and on payments specifically it does more than we do today. If you came here expecting us to explain that away, we won't. The difference is runtime shape and custody, and for a lot of teams MCPay is the right answer.
Self-host it. Charge for it. Hold no keys. Nobody else does all three — and this page is part of the working.
Start here
Which one you want depends on one question.
Do you need the money to actually move today, or do you need the thing in your payment path to be something you fully control?
Pick MCPay if
- You want on-chain settlement now — it verifies, settles, and retries the original request after payment
- You're a TypeScript shop and a Node runtime is what you already operate
- You're happy pointing settlement at a hosted facilitator and not running one
- Your upstreams are MCP servers, and only MCP servers
- You want the shortest path from "I have an MCP server" to "it charges"
Pick Farcaster if
- You need to self-host the whole path, facilitator included, with nothing pointed at a third party
- You'd rather deploy one static Go binary than a Node application
- You're fronting plain HTTP upstreams as well as MCP servers
- You need mandatory OIDC and per-tenant credential isolation, not API keys
- You can live with verify-only today, because settlement is on your own roadmap
Where they're ahead
They collect. We verify.
This is the real gap and it is not close. MCPay negotiates x402, confirms the payment on-chain, and automatically retries the original request once it has settled. Farcaster ships the gate: it checks that a signed authorization is valid, sufficient and unexpired, then forwards. No funds move.
Head-to-head on payments alone, we read as a step behind — because we are. That's a deliberate scope choice rather than an unfinished one: verification needs no key and no outbound call, so it can live in the free core, and collection is the part that requires somebody to hold a gas key. But if what you need today is money in an account, MCPay does that and our open-source gate does not.
One consequence worth knowing: with no settlement step to authoritatively consume the on-chain nonce, our gate-only replay protection is best-effort. Enabling settlement is what closes it. See the x402 gate.
Side by side
The rest of the surface.
| MCPay | Farcaster | |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Runtime | TypeScript / Node | One static Go binary |
| Deployment posture | Open source, hosted-leaning — the docs and examples point at mcpay.tech | Self-host first. Nothing phones home, and there is no hosted default |
| x402 | Verify + settle + retry | Verify (the gate). Settlement via a facilitator you run, or ours |
| Custody | Settlement is delegated to a facilitator service | The gateway holds no signing key, ever. The facilitator is separable and self-hostable |
| Auth | API keys | Mandatory OIDC bearer; the process refuses to start without an issuer and audience |
| Credentials | Not a separate resource | Envelope-encrypted under a per-tenant key, write-only, never echoed |
| Upstreams | MCP servers | MCP over Streamable HTTP, plus generic HTTP upstreams |
| Traction | ~91 stars, actively developed | Newer and smaller — which is also why it's one binary you can audit in an afternoon |
The actual difference
Who has to be trusted for a payment to work.
Both projects gate a call on a signed authorization. The question is what sits behind that gate. MCPay's settlement path runs through a facilitator service; ours is a separate component you can run yourself under the same license as the gateway, and the gateway never holds a key whether you run it or we do.
For most teams that distinction is worth nothing, and MCPay's shorter path wins. For an operator who is regulated, air-gapped, or under a data-residency rule, it's the only thing that matters — because "point settlement at someone else's service" is not a sentence they're allowed to finish.
Sources
Compared against publicly available information on 3 August 2026, verified directly rather than quoted from our own earlier research. MCPay: github.com/microchipgnu/MCPay and docs.mcpay.tech. If something here has gone out of date, tell us — open an issue and we'll correct it rather than leave it standing.