Sluice: Global Invariant, Local Enforcement for Pooled Payment-Channel Liquidity
Sluice proposes nested Lightning channel reservations that recover much of the liquidity lost to static quotas.
The cs.CR paper Sluice studies Lightning Network routing nodes whose payments fail on one exhausted channel while other channels still hold balance. Pooling liquidity requires a global reserve that each counterparty can enforce without a shared off-chain counter. On three Lightning snapshots, splitting the reserve into advance per-channel quotas forfeits 16% to 67% of the pooling gain, and the loss grows with channel count. Sluice keeps an exclusive per-channel base and authorizes shared overflow with certificates from a capacity-weighted quorum, recovering 19% to 65% of that loss while losing at most 1.3 points of payment success to coordination.
- Static per-channel quotas forfeit 16% to 67% of pooling gains.
- Nested bases and quorum certificates recover 19% to 65% of that loss.
- Conflicting certificates share an honest signer, so no slashable stake is required.
- Recreating only overflowed bases costs 0.5 to 1.2 times Lightning on-chain bytes.
Full article251 words · extracted from arxiv.org · click to collapse
A routing node on the Lightning Network holds its liquidity in separate channels, so a payment can fail at a channel whose outbound balance is exhausted while the node's other channels still hold balance. Pooling the channels into one reserve fixes this only if the node's draws across all channels stay within the reserve: a global invariant that each counterparty must enforce from its own channel, with no shared counter that off-chain draws can update. A node must therefore split the reserve into per-channel quotas in advance or coordinate every draw with every counterparty. On three Lightning snapshots the advance split forfeits $16$ to $67\%$ of the pooling gain over unpooled channels, and the loss grows with channel count. Sluice recovers $19$ to $65\%$ of that loss with a nested reservation: each channel keeps an exclusive base that its counterparty checks alone, and the rest is a shared overflow drawn on with certificates from a capacity-weighted quorum of the node's counterparties. Two conflicting certificates share an honest signer, so over-drawing is prevented without a slashable stake, under a stated bound on the capacity the node controls in the signing set. Sluice loses at most $1.3$ points of payment success to coordination where deployed coin movers lose up to $10.3$, and improves them in eleven of twelve cells when stacked on them. Re-creating every base output each epoch costs $2.8$ to $5.1$ times Lightning's on-chain bytes; re-creating only those that overflowed costs $0.5$ to $1.2$ times and keeps part of the gain.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arxiv.org/abs/2609.29975