Splicing

Splicing lets a Lightning node resize an existing payment channel — adding or removing funds — without closing it. The change is folded into a single on-chain transaction, and once confirmed, the splice transaction becomes the channel's new funding transaction. Crucially, the channel keeps operating throughout: payments continue routing over the old funding output while the splice confirms, so a resize that once meant days of disruption now means zero downtime.

What happens under the hood

A splice is a negotiation between the two channel peers. They interactively construct a new funding transaction that spends the current funding output, adds or removes the agreed funds, and pays the result to a fresh funding output for the same channel. Both sides exchange signatures for the new commitment transactions before the splice is broadcast, so the channel is never unenforceable at any moment. While the splice awaits confirmation, the implementations track both the old and new funding outputs in parallel, and once the new transaction confirms to a safe depth, the old state is retired. If fees spike, the pending splice can be re-negotiated at a higher fee rate, since the funding output it spends has not changed.

Splice-in and splice-out

A splice-in adds bitcoin to a channel, increasing its capacity — say, to support larger payments or to give a well-connected channel more routing headroom. A splice-out removes funds to an on-chain address, letting you pay an invoice, top up cold storage, or free capital from an over-provisioned channel without tearing it down. Both directions collapse what used to be two or three transactions into one, and a single splice can even combine operations — pay an on-chain destination and rebalance capacity in the same transaction the way an ordinary wallet batches outputs.

Why close-and-reopen was so costly

Before splicing, changing a channel's size meant closing it and opening a new one: two on-chain transactions, two fee payments, and a confirmation wait during which the capital routed nothing. Worse, closing destroyed things that take time to rebuild — the channel's track record in gossip, its position in peers' pathfinding scores, and the operational trust between two nodes that have routed cleanly together. For a routing node, that reputation is the business. Splicing preserves the relationship and its history while changing only the number that needed changing: the channel capacity.

How it fits the liquidity toolbox

Splicing complements rather than replaces the other liquidity tools. A submarine swap shifts balance within a channel's existing capacity by trading on-chain and off-chain funds with a counterparty; a splice changes the capacity itself. Circular rebalancing moves liquidity between your own channels for a routing fee. A node operator managing inbound liquidity ends up using all three, choosing by price: when on-chain fees are low, splicing is often the cleanest way to right-size a channel permanently instead of renting balance adjustments repeatedly.

Standardization and support

Splicing was developed openly through the BOLT specification process and negotiated between peers via Lightning's feature-bit system, meaning both endpoints must support it for a channel to be spliced. Implementation arrived unevenly — as with most Lightning features — so a self-hosted node's practical access depends on which implementation it runs and which peers it opens channels with. The design also pairs naturally with dual-funded channels, which use the same interactive transaction-construction machinery.

For the self-custodial node runner, splicing removes one of the last good excuses for custodial Lightning: capital management stops being a costly ceremony and becomes routine maintenance. Your channel is no longer a box you must smash to resize — it is a living balance you adjust as your needs change, with the Lightning Network none the wiser and your sats never in anyone else's custody.