Forwardable peerswaps pitch Lightning liquidity nobody can oversell
Serguey Asael Shinder2 min readLightning developer ZmnSCPxj has posted a design for "forwardable peerswaps" on Delving Bitcoin, pitched as an alternative to splicing for managing channel liquidity. The first post went up on 27 September; two follow-ups on 28 September tightened the design and corrected one part of it.
The core argument is about trust. When a service sells inbound liquidity through splicing, the buyer sees only its own channel. The author's example: if ten clients each buy 1.0 BTC of inbound from one provider that really has 2.0 BTC of inbound from the rest of the network, all ten stop receiving once 2.0 BTC has arrived, and none of them could have checked. In a swap the in-Lightning payment has to actually reach the counterparty, so the swap only completes if the capacity is real. "You atomically cannot buy a low-quality inbound liquidity product," he writes.
Forwarding is what makes it a new design: a swap can pass through several hops, each node seeing only its own channels, so no one has to reveal channel balances. On chain space, a forwarded swap costs two transactions however many channels it rebalances, while a splice grows with each channel it touches.
The follow-ups deal with "surreptitious tunnels", fields through which the two ends could identify each other and cut out the forwarders. The author proposes standard swap amounts, from 10 BTC down to 0.0001 BTC, and a fixed timelock of 2,016 blocks. In the third post he called part of his own key scheme "wrong and broken", because one value could still leak the node's identity, and replaced it with a MuSig2 construction.
Why it matters
Liquidity is Lightning's most expensive operational problem, and most current answers ask the buyer to trust the seller's numbers. This is still a forum proposal with no implementation announced, but the self-correction within a day is how such designs are meant to be tested.