Splicing jointly changes a Lightning channel’s funding: a new on-chain transaction spends its current funding output and creates a new one. The parties also prepare matching commitment transactions, signed transactions for a possible channel close. It continues the same channel rather than performing a normal close followed by a separate opening.
A splice-in adds funds to the contributing party’s balance; a splice-out moves part of that balance to an output outside the channel. Contributions also affect total capacity; if they cancel each other out, capacity can remain unchanged. The channel’s funds are always anchored in a different Bitcoin funding output. A normal cooperative close and subsequent opening are not required. [1]
The channel first enters quiescence, a brief pause in incompatible updates. The initiator sends splice_init and its peer replies with splice_ack. Their jointly built transaction must have exactly one input spending the old funding output and exactly one new output funding this channel; other inputs and outputs can add or withdraw funds. The parties then exchange commitment_signed and tx_signatures with the relevant signatures. [1]
After transaction signatures are exchanged, payments can resume while the parties await an acceptable confirmation depth. Nodes therefore maintain commitment states for the original funding, the new splice and any RBF replacements simultaneously. A payment must be valid across all active variants. Reconnection requires restoring the correct unfinished state; keeping only one latest transaction is insufficient. [1] [2]
Both nodes must negotiate option_splice support and accept the transaction, fee rate and contributions. A peer may reject the proposal using tx_abort. Until both parties acknowledge the same splice with splice_locked, new updates must cover all active commitment transactions. One party cannot unilaterally rewrite the other’s balance. [1] [3]
Core Lightning version 26.04 enabled Splicing by default. It added splicein and spliceout commands and transfers between two channels, called cross-splice. The other node’s version and supported channel type still matter. The same feature name in different wallets does not establish identical capabilities or interoperability. [4]
Splicing still creates a Bitcoin transaction, so on-chain fees, confirmation and possible reorganizations still matter. Eclair, for example, offers rbfsplice to raise the fee rate of an unconfirmed splice. Operators must respect channel reserves, confirmed-input requirements, contribution and repeated-RBF limits, and backup state. The special option_zeroconf mode changes trust assumptions, and the protocol forbids RBF in that mode. [1] [5]
Once the chosen splice reaches acceptable depth and both parties exchange splice_locked for the same txid, they can stop maintaining old and unsuccessful variants. The funding outpoint, the reference to a specific transaction output, changes; capacity changes according to the sum of contributions. A public channel also gets a new short_channel_id derived from the confirmed transaction, and the parties can prepare new announcement_signatures. [1]
Check both nodes’ support, channel_id, the sign and size of funding_contribution_satoshis, fee rate, inputs, outputs, reserves and signatures. Track the txid of every RBF variant. After completion, compare splice_locked, the new funding outpoint and, for a public channel, short_channel_id. Also check that HTLC operation has resumed and that the withdrawal output really belongs to the intended wallet. [2] [1]
For the clearest picture, read this entry together with Payment Channel, Lightning Network, UTXO, Lightning liquidity, Replace-by-Fee (RBF), Price Channel. The reverse links also lead from Lightning liquidity.
01Is Splicing the same as closing and reopening a channel?+
No. Splicing also creates a Bitcoin transaction, but the parties jointly move the existing channel to a new funding output. A normal close ends the old channel, and a later opening creates a separate channel.
02Can funds be both added and withdrawn?+
Yes. A positive contribution is a splice-in and a negative one a splice-out. Both parties must accept the change, and the transaction must respect balances, reserve rules and fees. The sum of both parties’ contributions determines the resulting capacity.