Skip to main content
Paychannels move millions of payments per second by keeping them offchain between settlements. That speed comes from a hub operator who orders and applies payments. This page explains what that operator is trusted for, what it is prevented from doing, and how anyone can check its work. The short version: the operator processes payments but never holds the money, and it cannot settle anything that independent verifiers have not checked. It is trusted for ordering and liveness between settlements, and its verifiers can audit that trust in full.

​
Who holds the money

Deposits live in the hub’s channel contract on Polygon, not with the operator. The contract releases funds only in two ways:
  • Against a settlement that a threshold of verifiers has signed.
  • To the account that owns the balance. A withdrawal can be submitted by anyone, but the payout always lands on the account itself.
The operator has no key that can move a deposit. Payments themselves are vouchers signed by the payer’s session key, and the hub applies only vouchers that carry a valid signature for that payer.

​
Every settlement is verified

Periodically, the hub closes an epoch and summarizes every account’s balance into one Merkle root. Before that root can be posted, it needs signatures from t of N verifiers registered on the hub’s contract (for example, 2 of 3). Each verifier independently:
  1. Downloads the evidence for the epoch from the hub: every voucher and the resulting ledger.
  2. Re-verifies every voucher signature.
  3. Recomputes the ledger arithmetic and the root.
  4. Signs only if everything matches.
The contract rejects a root without enough valid signatures. There is no operator-only path and no unverified redemption. Verifiers cannot move funds. They can only refuse to sign. A partner that does not want to trust the operator’s node can run its own verifier and have it added to the hub’s onchain verifier set. Changes to that set are delayed onchain, so a rotation is visible before it takes effect.

​
What the operator can and cannot do

Every settlement is also checked for solvency: no account in a root can have spent more than its deposits plus what it has received.

​
Limits to plan around

Two properties are trusted to the operator rather than enforced onchain. Liveness. Withdrawals need a posted settlement. If an operator stops posting, withdrawals already reserved in a posted settlement stay redeemable with a Merkle proof and no operator involvement. New earnings since the last settlement cannot be withdrawn until a new one is posted. Frequent epochs keep that window short. Ordering within an epoch. Between settlements, the operator decides the order in which payments and withdrawal reservations apply. A dishonest operator could reorder them inside one epoch. The effect is limited to reordering, never an over-payout. Misbehavior in either case is detectable after the fact: anyone can see from onchain data that settlements have stopped, and verifiers can see reordering in the epoch evidence. Neither is prevented onchain.

​
When a receipt is final

A hub returns a receipt the moment it applies a payment. For maximum throughput, a hub can acknowledge a payment once it is applied in memory and queued for its journal, before it reaches disk. If the hub crashes in that brief window, the most recent acknowledged payments can be lost. Those payments were never part of any settlement, because settlements cover only durably recorded payments. A payer cannot be double-charged on retry, because vouchers carry a running total. A receipt becomes durable evidence once the hub records it in its payment feed, which the operator and verifiers read. Operators who want acknowledgment only after a durable write can run the hub in fsync mode at lower throughput.

​
Spending commitments

A voucher authorizes a running total, not a single payment. Signing a voucher for a total of 500 lets the hub serve up to 500 to that merchant. Sign only totals you are willing to see spent. Keep the payer key that made the deposit offline. The session key signs payments, so it must stay on the machine that pays. A leaked session key can sign vouchers against your existing deposit, but it cannot withdraw funds or send them anywhere else.

​
Auditing a hub

Checking a hub’s work splits between what anyone can read and what only the operator and its verifiers can read. Public data. Anyone can check the following without the operator’s cooperation: From these you can confirm that every posted root carries signatures from a threshold of the hub’s registered verifiers, and track the money entering and leaving the channel contract. Operator and verifier data. The hub’s payment feed, which lists every payment the hub applied in a strictly increasing, gap-free sequence, and the full leaf set and evidence for each closed epoch are readable only by the operator and the hub’s verifiers. Verifiers use them to confirm that no payment is missing and to recompute each root before they sign it. A partner that wants to run these checks itself can run a verifier. Account owners. Each account owner can read their own balance, payments, and settlement proof by signing the request (see Privacy), and can check that proof against the root posted onchain.