Sluice: Global Invariant, Local Enforcement for Pooled Payment-Channel Liquidity

2026-09-24

AI Summary

This study addresses the liquidity fragmentation and capital inefficiency in Lightning Network channels caused by pre-allocation. To mitigate these issues, this work proposes a nested reservation architecture that combines exclusive base quotas with certificate-based shared overflow pools, enabling local execution under global invariants. Furthermore, it introduces an anti-overspending certificate mechanism that eliminates the need for slashable stakes, utilizing capacity-weighted quorums to coordinate cross-channel liquidity. By optimizing cryptographic certificate verification and on-chain output reconstruction, the proposed approach recovers 19%–65% of liquidity gains while incurring less than a 1.3% degradation in payment success rates. These results demonstrate significant improvements over existing solutions, offering a practical and efficient framework for enhancing liquidity utilization in payment channel networks.

Abstract

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.

Problem

• Lightning Network
• payment-channel liquidity
• liquidity pooling
• global invariant
• local enforcement

Innovation

• Lightning Network
• payment-channel liquidity pooling
• nested reservation
• capacity-weighted quorum
• global invariant