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 that trust is auditable from public data.

​
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 from published data. It is not 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 it appears in the hub’s public payment feed. 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.

​
Audit a hub yourself

Everything needed to catch a dishonest operator is public. Anyone can act as a watchtower using: From these you can check that money out equals money in across the whole hub, that no payment is missing from the feed, and that each posted root matches the leaves the hub disclosed. A failed check is publicly demonstrable, since anyone re-running it against the same inputs gets the same result.