Run a hub.
Brand it yours.
Your facilitator, your edge, our hub. The hub is one binary: a sharded ledger of payment channels that verifies and applies every payment and settles a million of them in one transaction. Put your CDN in front, your facilitator beside it, your name on the receipt — and sell the fastest payment rail in the world as part of your stack.
Run a hub
One binary, one box: ≈450k fully-verified payments/s on 16 vCPU. Add a hub, add that again.
BEmbed the facilitator
An open x402 facilitator that streams into hubs over gRPC. Fold it into your edge, your gateway, your API platform.
CSell it as your product
Per-request billing for every API behind you. Your merchants add one line; you own the relationship, the volume and the margin.
What a hub is.
A hub holds payment channels. A payer deposits once into the hub's contract on Polygon and binds a session key; from then on every payment is an EIP-712 voucher the hub verifies (real ECDSA, every payment), applies to a sharded in-memory ledger, and journals to disk. Nothing touches the chain per payment.
Once per epoch the hub posts one Merkle root covering every payment. That is 1 on-chain transaction per epoch per hub — ≈112,525 gas — no matter how many payments, no matter how many payers. Cashing out is a separate requestWithdraw + withdrawAttested (≈96,733 gas per account).
Hubs are shard-independent, so capacity is additive: 100 hubs measured 45,017,796 fully-verified payments a second, durable, for 600 s on 2026-10-08 — ≈450k/s per 16-vCPU hub (hub-ingress tier, one Ed25519 signature per payment; method).
Crash-safe by construction: an fsync'd journal plus snapshots, kill -9 under load and restart with zero acked loss. Every epoch root is co-signed by a verifier quorum that re-checks the evidence before it can post.
Your edge, our hub.
The facilitator is the x402 spec surface — /verify, /settle, /supported, /quote — and it is open: any payTo, no allowlist, no registration. It decodes an X-PAYMENT into a 240-byte binary item and streams it to a hub over long-lived gRPC streams; the hub verifies, journals and acks it. Put it wherever your requests already terminate.
A merchant's 402 is a static body. It can live in your cache. The only origin-bound work per payment is one /settle passthrough — which means an edge-native paywall: the 402 from the CDN, the settle from the nearest facilitator, the money in the hub.
- x402
exactand thebatch-settlementchannel scheme, one API - Works with the official x402 SDK and every EVM wallet
- Per-payer and per-IP rate limits, a persisted gas budget,
/readyzfor your load balancer - Idempotent settles: a retry converges to the original receipt, never a double charge
- Serve one hub or a hundred from one facilitator; serve one facilitator per region
Sell it as your product.
For a network
Human commerce bundles; agent commerce streams. A card network charges 30,000 % on a tenth of a cent. A hub charges $0 per payment. Run the rail the agents will actually use — with your brand on the receipt and your settlement on your books.
For an edge
You already terminate the request. Add the facilitator next to it and every API behind you can bill per call with one line of middleware. Payments settle in the hub before the response leaves your edge.
For an API platform
Turn every endpoint in your catalogue into a paid endpoint. Your customers keep the price; you keep the volume, the data and the margin on the rail.
What a hub costs you
Change any input. vCPUs follow from the measured hub vCPU-time per payment; servers are whole 16-vCPU boxes; the price is yours.
Defaults from the 100-hub run: 1,600 hub vCPU ÷ 45,017,796 payments/s ≈ 35.5 vCPU-µs per payment (rounded up); a 16-vCPU Hetzner CPX62 at its list price. At those numbers a billion payments cost cents to process. Change the price to yours.
Start with the devnet.
The hub and facilitator are operated by us; talk to us about running your own. The live devnet is open today: point an agent at it, have it build a load generator from the public protocol, and read the numbers off the explorer.
Read https://paychannels.mudit.blog/PAYING.md and https://paychannels.mudit.blog/STRESS-TESTING.md. Open a channel on the Paychannels devnet, build a small load generator, and report the sustained payments/s and latency percentiles with the run shape.