arXiv:2609.29975v1 Announce Type: cross 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 e
Sluice is a protocol introduced in arXiv:2609.29975 (submitted September 24, 2026) that enables pooled payment-channel liquidity on the Lightning Network by enforcing a global invariant through local checks. It solves the problem where a routing node’s payment fails due to exhausted balance in one channel, even if other channels hold sufficient funds, by allowing channels to draw from a shared overflow reserve.
The protocol uses a nested reservation system: each channel retains an exclusive base checked independently by its counterparty, while additional liquidity is accessed via a capacity-weighted quorum of counterparties. This approach recovers 19% to 65% of the pooling gains lost to advance splitting, with coordination overhead limiting payment success by at most 1.3 points, significantly outperforming existing mechanisms like Shaduf and Horcrux.
Sluice targets a common liquidity-fragmentation problem in Lightning Network routing: a node may have sufficient total liquidity across its channels, yet a payment can fail because the particular channel needed for the route has exhausted its outbound balance. The paper frames this as an accounting and enforcement problem rather than merely a channel-management problem. Its central proposal is to let a routing node pool the usable liquidity of multiple channels into a single logical reserve, so that routing can draw on aggregate node liquidity instead of being constrained by the balance of any one channel.
The key contribution is the separation of a global invariant from local enforcement. The invariant is that the node’s total pending or committed outbound draws across all pooled channels must not exceed the shared reserve. Sluice enforces this invariant locally by tracking pending commitments and checking each prospective payment against the pooled reserve before it is accepted or forwarded. In effect, a channel can carry a payment if it has local capacity and the global pool is not overdrawn, while the mechanism prevents the node from committing more outbound liquidity across its channel set than it actually controls. This preserves the per-channel commitment and settlement structure of the Lightning Network while allowing more flexible use of idle liquidity.
The work matters because it can improve payment success, reduce the need for frequent rebalancing, and lower the capital and operational cost of running routing nodes with many channels. Instead of requiring liquidity to be pre-positioned in every channel, Sluice lets a node use surplus liquidity from other channels to support routing decisions. More broadly, it offers a useful design pattern for distributed payment systems: maintain a shared accounting invariant globally, but enforce it through local, per-channel checks, which supports scalability, reliability, and more efficient liquidity utilization in channel-based networks.