LIGHTNING
← Topics

Channel Splicing BOLT Merged

Resize Lightning channels without closing them — 8 years in the making

~8yr
CONCEPT TO SPEC
3/4
IMPLS READY
1 tx
NOT 2
WHAT IS SPLICING
Spending the current funding transaction to create a new one with different capacity, without closing the channel. Splice-in adds funds; splice-out removes funds to an on-chain address. The channel stays usable throughout — payments keep flowing while the splice tx confirms. Previously, resizing required two on-chain txs (close + reopen) and channel downtime.
"DEATH TO ALL SWAPS"
Splicing replaces submarine swaps for moving funds between on-chain and Lightning. No trusted intermediaries, no double on-chain fees, predictable feerates you control directly. Creates fungibility between on-chain and Lightning bitcoin — enabling "one balance" wallets where users see unified liquidity. Phoenix wallet already cut fees ~60% using this architecture.

How It Works

1. QUIESCENCE (STFU)
Either peer sends stfu ("SomeThing Fundamental is Underway") to pause the channel. The responder acknowledges after completing any pending HTLCs. This ensures both peers have the same view of current commitments.
2. NEGOTIATE & CONSTRUCT
Initiator sends splice_init, acceptor responds with splice_ack. Using interactive-tx (same protocol as dual funding), peers take turns adding inputs and outputs. The existing funding UTXO is always an input. Both sides can batch additional operations — splice + channel open + on-chain payment in one tx.
3. SIGN, BROADCAST & CONTINUE
Peers exchange tx_signatures and broadcast the splice. The channel immediately resumes — commitment txs are rebuilt for every pending splice simultaneously. After confirmation, peers exchange splice_locked and the new funding output takes over. Supports RBF (fee bump if stuck) and concurrent splices.
THE COMPLEXITY
Multiple splices can be pending at once, each with its own commitment transaction set. Reconnection logic (channel_reestablish extensions) was the most debated part of the spec — synchronizing splice state after disconnection took months of back-and-forth between t-bast and Dusty Daemon.

Implementation Status

IMPLEMENTATIONSTATUS
Eclair (ACINQ)Full support — incl. RBF, public channels, taproot splicing
Core LightningExperimental since v23.08 — interop with Eclair confirmed
LDKExperimental in v0.2 — cross-compat tested Jan 2026
Phoenix WalletProduction since Jul 2023 — splicing as core architecture
LNDNot yet — quiescence added, taproot prep merged Mar 2026
SPEC PR DETAILS
PR #1160 by t-bast (ACINQ), merged March 23, 2026. Clean rewrite of original PR #863 (Rusty Russell, 2021). Feature bits 62/63. +1,721 lines across BOLT 2, BOLT 7, BOLT 9, plus test vectors. Depends on quiescence protocol (PR #869, merged June 2024). Rusty Russell ACK'd March 9, 2026.
LND GAP
The largest Lightning implementation by node count cannot participate yet. LND has quiescence support and taproot nonce coordination (PR #9982, March 2026), but full splicing remains unimplemented. This limits network-wide adoption until LND ships support.

Timeline & Resources

THE LONG ROAD
Jun 2018: Concept proposed by Rene Pickhardt; detailed spec by Rusty Russell later that year

Apr 2021: First spec draft (PR #863) opened

May 2022: World's first splice on-chain (Dusty Daemon via CLN)

Jul 2023: Phoenix ships splicing in production; CLN experimental

May 2024: t-bast rewrites spec as PR #1160 (cleaner edge-case handling)

Jan 2026: Cross-compat confirmed between Eclair, CLN, and LDK

Mar 2026: BOLT merged — splicing is officially part of the Lightning spec