Paychannels
07 · Platforms

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 a payment in 32.3 µs 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.

A

Run a hub

One binary, one box, 465k fully-verified payments/s on 24 cores. Add a 48-core hub, add a million a second.

B

Embed the facilitator

An open x402 facilitator that streams into hubs over gRPC. Fold it into your edge, your gateway, your API platform.

C

Sell 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.

A

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. Each merchant claims with one proof. That is 2 on-chain transactions per epoch per hub — ≈74,000 + ≈90,000 gas — no matter how many payments, no matter how many payers.

Hubs are shard-independent. Capacity is additive: 465k/s on one 24-core box, 5.84M/s across eleven, ≈22.6k per core. Twenty hubs is ten million payments a second. Two hundred is a hundred million.

32.3 µshub verify + apply, per payment
5.84M/s11 hubs · 258 cores · fully verified
2on-chain transactions per million payments
9 msfor one hub to clear a card network's peak second

What you run

one hub · engine serve
engine serve \
  --listen 0.0.0.0:9100 --grpc-listen 0.0.0.0:10100 \
  --hub $HUB_ADDRESS --asset $USDC_ADDRESS --operator-key $OPERATOR_KEY \
  --rpc-url $RPC_URL --chain-id $CHAIN_ID \
  --data-dir /var/lib/paychannels/hub0 \
  --epoch-interval-secs 600
your facilitator
facilitator \
  --listen 0.0.0.0:9200 \
  --rpc-url $RPC_URL --chain-id $CHAIN_ID --deployments deployments/<network>.json \
  --engine-url http://hub0:9100 --engine-grpc http://hub0:10100 \
  --hub-streams 4 --hub-inflight 1024

Crash-safe by construction: an fsync'd journal plus snapshots, kill -9 under load and restart with zero acked loss. Every read surface — payments, epoch proofs, closed-epoch leaves — is public so anyone can recompute your roots.

B

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 acks in microseconds. Run 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 exact and the batch-settlement channel scheme, one API
  • Works with the official x402 SDK and every EVM wallet
  • Per-payer and per-IP rate limits, a persisted gas budget, /readyz for 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
C

Sell it as your product.

For a network

Human commerce bundles; agent commerce streams. A card network peaks near 9,000 payments a second and charges 30,000 % on a tenth of a cent. A hub does that volume every 9 ms at $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. Cores follow from the hub's measured µs per payment; servers are whole 48-core boxes; the price is yours.

1.16M/ssustained rate
34.7cores busy
1servers (48-core)
$100per month
$0.024per billion payments

Defaults: hub verify + apply per payment rounded to 30 µs; a 48-core server at $100 a month. At those numbers a billion payments cost cents to process. Change the price to yours.

→

Start with a fleet.

Everything is open source. just demo runs the whole payment path on one machine and just demo-local 11 scales the devnet to eleven hubs locally; the eleven-hub benchmark evidence is archived under demo/fleet/archives/. Or hand the whole thing to an agent:

paste into your agent
Read https://paychannels.mudit.blog/STRESS-TESTING.md and https://paychannels.mudit.blog/MERCHANTS.md. Stand up a Paychannels hub and facilitator on my infrastructure from https://github.com/mudit-polygon/thunderpolt, front it with my edge, and run the fleet benchmark. Report fully-verified payments/s per hub and the scaling curve.

Every tier, methodology and archive → · GitHub · live explorer · Talk to us