Splicing
Splicing is a Lightning Network protocol that spends a channel's current funding output into a new funding output with a different amount, so peers can add or remove on-chain funds without closing the channel. Feature bits 62/63 advertise option_splice. The construction reuses interactive transaction building from Dual funding.
Without splicing, changing capacity usually means a close and a new open, which is slower, costs more on-chain fees, and drops the channel from the public graph while it is down. A splice-in adds funds. A splice-out withdraws to an on-chain address. Moving value into another of the same node's channels is sometimes called a cross-splice.
Negotiation
Peers first quiesce the channel (BOLT 2 option_quiesce / stfu) so both sides share the same committed state with no in-flight updates. They then negotiate amounts and feerate, build a transaction that spends the current funding output (plus any extra inputs) into a new funding output and optional splice-out outputs, and exchange signatures for that splice and for commitments that spend the new outpoint. Commitments that still spend the old outpoint are kept until the splice confirms. After un-quiescing, new HTLCs must remain valid against every pending funding outpoint so a late confirmation cannot strand a payment. The splice may be fee-bumped with Replace by fee by repeating construction. When a splice reaches the required depth, peers exchange splice_locked, drop competing pending splices and the old funding outpoint, and advertise the new short channel id.
Quiescence prevents concurrent commitment updates from racing the interactive splice builder. Peers that cannot quiesce safely should refuse option_splice until both sides implement stfu.
Fee bumps
Because the splice spends the current funding outpoint, a stuck low-feerate splice blocks capacity changes until it confirms, is replaced, or is abandoned per peer policy. Peers repeat interactive construction with a higher feerate and exchange fresh signatures, using Replace by fee on the unconfirmed splice transaction. Anchor-style or TRUC fee-bumping on the splice itself depends on the channel's commitment format and on whether the splice transaction opts into version-3 policy. If peers disagree on whether a replacement splice is valid, one side may need to force-close using the latest commitment that still spends a funding outpoint both sides acknowledge.
Pending state
Splicing needs no consensus change. Taproot channels splice into a new P2TR funding output. Legacy channels splice into a new P2WSH 2-of-2. Until splice_locked, watchers must track every pending funding outpoint.
While a splice is pending, the channel may keep serving HTLCs, but both peers must be prepared to settle those HTLCs against either the old or the new funding outpoint. Public channels update gossip after splice_locked so the network learns the new capacity and short channel id. Until then, routers may still advertise the pre-splice capacity. Failed or replaced splices must not leave orphan commitment signatures that spend a discarded outpoint.
A node that restarts mid-splice must reload every unfinished funding outpoint from durable storage before accepting new HTLCs, or it may sign commitments against a discarded txid.
After splice_locked, nodes should forget superseded funding outpoints promptly so monitors do not keep watching dead txids. Public capacity advertisements that lag the locked splice can cause temporary routing failures toward the old short channel id.