Key points

  • Sluice divides a routing node's funds into channel-specific base balances and a shared overflow reserve.
  • The paper reports recovering 19% to 65% of the pooling gain lost to static allocation in simulations using three Lightning snapshots.
  • The design is a research prototype, not a deployed upgrade, and would require Lightning channel-format changes rather than a Bitcoin consensus fork.

Researchers from Peking University and Beijing Normal-Hong Kong Baptist University have proposed a way for Bitcoin Lightning routing nodes to share liquidity across multiple payment channels. The paper, titled Sluice, was published as a preprint on September 24. It targets a persistent operational problem: funds committed to one channel cannot normally be used when demand unexpectedly shifts to another, even when both channels belong to the same node.

A shared reserve sits above channel balances

Sluice would split a node's liquidity into two layers. Each channel keeps an exclusive base balance for ordinary payments, while overflow funds sit in a pool that several channels can draw from. A channel may consume pooled value only after collecting a capacity-weighted quorum certificate from the other participating channels. The authors say that certificate gives local counterparties enough information to enforce a node-wide solvency rule without requiring a global ledger for every off-chain payment.

Related reporting: Lightning bug could mark canceled Bitcoin invoices as paid

The proposal addresses stranded capacity

Lightning payments travel through bilateral channels whose balances are updated off chain and can ultimately be enforced on Bitcoin. That structure improves speed and reduces settlement load, but liquidity remains directional and channel-specific. Routing operators can rebalance channels or open new ones, yet those measures add cost, latency or operational complexity. A common reserve could make spare capacity available where it is needed while retaining the channel model described in the original Lightning paper.

Simulations show gains with coordination costs

The researchers evaluated Sluice against static allocation and deployed coin-moving techniques using three historical Lightning Network snapshots. Their simulations found that assigning the pooled reserve in advance forfeited 16% to 67% of the potential pooling gain. Sluice recovered 19% to 65% of that lost benefit and outperformed the compared alternatives in 11 of 12 evaluated settings. The paper reports coordination losses of no more than 1.3 percentage points, versus as much as 10.3 points for deployed coin movers.

Safety adds on-chain and messaging overhead

Those improvements are not free. The design adds certificate exchanges before pooled funds can be used and expands the data needed for channel enforcement. The paper estimates that fully anchoring the construction could require 2.8 to 5.1 times Lightning's on-chain bytes, although the incremental overhead after accounting for existing channel transactions is estimated at 0.5 to 1.2 times. Its prototype produced a certificate in roughly half a millisecond, while an end-to-end coordination round was modeled at about 0.2 to 0.5 seconds.

No Bitcoin consensus change is proposed

Sluice does not rely on a Bitcoin covenant or consensus fork. It would, however, require changes to Lightning's channel commitment format and a negotiated feature bit, meaning wallets and nodes would need to implement and coordinate support. Existing Lightning specification work, including the BLIPs repository's liquidity-service proposals, shows that liquidity management can evolve at the protocol-service layer, but Sluice introduces a different pooled-reserve model with new trust and availability assumptions among channel participants.

The results remain preliminary

The numbers are results reported by the paper's authors from simulations and a prototype, not evidence from a production Lightning deployment. The preprint has not established adoption, and routing operators would need to weigh liquidity efficiency against larger settlement footprints, extra messaging and the risk that unavailable participants delay access to shared funds. Sluice nevertheless offers a concrete design for treating a routing node's fragmented balances as one coordinated resource while preserving Bitcoin's existing consensus rules.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.