Channels Too Small to Settle
John Law, Delving 15 Sep 2026. The post is a design for people whose Lightning balance is smaller than the fee to put that balance on chain.
THE GAP HE NAMES
A trust-free protocol, in his framing, cannot at once use about 1–2 vbytes per user per year, let people join without paying an on-chain fee themselves, and avoid a pile of off-chain transactions that cannot be published before someone can steal. He says no existing trust-free design hits all three, so most users are expected to stay on custodians.
DEPOT
One operator puts up a single Taproot output. Thousands or millions of users buy off-chain Lightning channels against that output. Neither side can take the other's funds outright. Each side can force the other to lose money only by losing a proportional expected amount of their own.
Most Channels Never Hit
A channel pays X sats only if it is published. The user pays X/P. P is a large prime.
THE BET
To buy a channel that pays X sats if it is published, the user pays X/P sats. P is a large prime, his example range is a hundred thousand to a billion. The user's guess is committed so the operator does not learn it. After expiry the operator reveals a target. A hit is a guess that matches.
ONE HIT
If exactly one channel hits, that user and the operator split the depot on chain, and the user is paid P times what they paid for the channel. If nobody hits, the operator claims the output after a delay.
TWO HITS
If more than one channel hits, the depot's funds are burned. That is the penalty that is supposed to stop the operator from selling so many channels that a safe target no longer exists, and to push users to drain before expiry.
DRAIN
Users are supposed to empty channels before expiry, by Lightning payments or by moving to another depot, and to reveal the guess so the operator can pick a target that misses. Channels that were drained do not have to appear on chain.
It Needs CTV and CSFS
Depots are not a policy idea. The scripts he draws do not exist on Bitcoin today.
REQUIRED
OP_CHECKTEMPLATEVERIFY (BIP-119) fixes the shape of the child transaction. OP_CHECKSIGFROMSTACK (BIP-348) lets the operator's signature cover a commitment to the user's hidden guess. Without both, the construction does not work.OPTIONAL
He says PairCommit,
OP_MUL, and OP_MOD make depots much smaller, and are not required for the basic protocol. Those are further opcodes, not part of CTV or CSFS.HIS SCALE CLAIM
With one depot created per block, he says depots could give 10 Lightning channels to each of 10 billion users and carry over 900,000 payments per second, using little block space. That is his analysis of the design, not a measurement of a running system.
Security Is a Penalty Ratio
He does not claim the protocol is safe against an operator who is willing to lose money. He claims a self-interested operator will not grief.
GRIEF RATIOS
Two parameters, GrO and GrU, bound the expected loss. His example: a GrO of 0.05 means that if the operator costs users an expected x, the operator must expect to lose at least 0.05x. He says values of 0.10 and 0.50 still give a reasonably efficient depot, and that any positive ratio deters a party who only cares about their own funds.
WHAT IT INHERITS
The argument leans on Lightning's record: people rarely grief even when there is no financial penalty, because reputation and the ultimatum game make burning value unattractive. A depot user who cannot afford to publish a non-hit channel is trusting that this keeps holding after expiry.
ON THE THREAD
Users must drain before expiry. Anzus, from GemWallet, asked what happens to a user who loses a device or misses the deadline, and whether wallets could move users to a new depot automatically.