Imagine you run a bar with five cash registers, each loaded separately. A customer at register 3 gets told "insufficient funds" even though registers 1, 2, 4, and 5 are flush. The obvious fix — one shared till — works great until you realize each cashier can only see their own drawer. That's the Lightning Network's liquidity fragmentation problem, and Sluice is a protocol for letting cashiers draw from the shared till using signed permission slips from their coworkers, without anyone ever seeing the full balance. The committed claim: Sluice introduces a nested reservation structure where each payment channel keeps an exclusive base amount that its counterparty verifies alone, plus a shared overflow pool accessible via capacity-weighted quorum certificates. Two conflicting overflow certificates necessarily share an honest signer, so over-drawing is cryptographically prevented without slashable bonds — under the assumption the node doesn't control too much capacity in its own signing set. This is a genuine architectural novelty for off-chain payment networks. The ladder context matters. The naive approach to pooled liquidity is to pre-split the reserve into per-channel quotas before any payments flow. On three real Lightning Network snapshots, this advance splitting forfeits 16–67% of the theoretical pooling gain compared to unpooled channels, and the loss worsens as channel count grows. Existing deployed coin-moving heuristics (the current practical SOTA for routing optimization) lose up to 10.3 percentage points of payment success rate to coordination overhead. Sluice caps that coordination loss at 1.3 points and improves on deployed heuristics in 11 of 12 experimental cells. These are simulation numbers on real topology snapshots, not synthetic graphs. Architecturally, Sluice sits in the family of threshold-cryptography-based off-chain coordination protocols. It leans on two structural properties: the capacity-weighted quorum design guarantees that any two valid certificates for conflicting draws must share at least one honest signer (a pigeonhole argument, not a complex cryptographic proof), and the nested base-plus-overflow structure lets most channel updates proceed with zero coordination — only overflow draws require quorum interaction. The on-chain cost is the main tradeoff: re-creating every base output each epoch costs 2.8–5.1× Lightning's current on-chain byte footprint, but the lazy variant (re-creating only overflowed outputs) drops to 0.5–1.2×. Integrity is reasonable but bounded. Validation is simulation on three real Lightning Network topology snapshots — not a testnet deployment, not a live experiment. The baselines are real deployed coin-moving algorithms, which is honest (they didn't pick a straw man), but the threat model assumes a bound on adversarial capacity in the signing set that hasn't been empirically validated against actual Lightning topology concentration. The 11-of-12-cells improvement is a strong signal but the cells are defined by the authors' own parameter grid. The milestone to watch is on-chain cost convergence. The lazy recertification variant at 0.5–1.2× Lightning's baseline bytes is already viable; the question is whether this holds as channel counts scale beyond the snapshot sizes tested. If a node with 50+ channels can maintain the lazy variant below 1.5× overhead while recovering >40% of pooling gain, this becomes deployable. The gap is probably 1–2 years of engineering plus a testnet pilot. The experiment the authors didn't run — and almost certainly want to for the next paper — is a live testnet deployment with adversarial nodes attempting to exploit the capacity-weight assumption. The signing-set honesty bound is the load-bearing assumption, and simulation can't stress-test it the way an adversarial testnet can. My read: this is (a) compute/engineering budget, not (b) a hidden negative result. The theory is clean enough that they'd want to show it working live, but building the infrastructure is a different kind of work.
