Splice-In

Splice-in is the act of adding fresh on-chain bitcoin to an already-open Lightning channel using one cooperative transaction, while the channel stays alive. Before splicing, the only way to grow a channel was to close it and open a larger one, which cost two on-chain transactions, paused the channel for the duration, and reset its operating history. Splice-in folds new UTXOs into the existing funding output so capacity increases without the channel ever going offline — the Lightning equivalent of renovating a room without moving out of the house.

One transaction, no downtime

Both peers cooperatively build a transaction that spends the current funding output plus the new inputs, producing a new, larger funding output that the channel immediately continues from. Off-chain balances and the channel's operating history carry over, so payments can resume as soon as the splice is broadcast — often before it even confirms, in implementations that support chaining onto the unconfirmed new funding output. During the window before confirmation, the peers track both the old and new channel states so that either outcome on-chain leaves them safe; once the splice transaction confirms to sufficient depth, the old funding output is history and the enlarged channel is the only reality. Because the splice spends the existing funding UTXO, it also composes naturally: the same transaction can add funds, and other inputs and outputs can ride along.

Why operators use it

Splice-in is how a routing node tops up outbound liquidity on a profitable channel, or how a merchant adds capacity to a channel that is performing well, all without the fee and downtime penalty of close-and-reopen. It also avoids fragmenting funds across many small channels: instead of opening a second channel to the same peer — which splits capital, doubles on-chain footprint, and worsens routing — the operator deepens the channel that is already earning. Fewer, larger, well-placed channels are generally better for the network's routing topology, and splicing is the tool that makes growing them cheap.

What it changes for a home node

For a sovereign node runner on the Lightning Network, splicing collapses the old mental model of channel funds as locked-in commitments. A channel becomes closer to an account whose on-chain backing can be resized as life demands — add savings when fees are low, without sacrificing the channel's routing reputation or waiting through close-and-reopen. Note the direction of what splice-in fixes: it adds outbound capacity, your ability to send. If what you lack is capacity to receive, that is the separate problem of inbound liquidity, addressed by different tools such as a submarine swap or simply spending through the channel.

The other half

Support has been arriving implementation by implementation rather than all at once, so check what your own node software and your channel peers can do before counting on it — a splice requires both sides to speak the protocol. Where support exists, it quietly removes one of the oldest frictions in Lightning operations; where it doesn't yet, the close-and-reopen fallback still works, just at the old cost. As adoption spreads, expect wallet interfaces to stop surfacing splicing as a named feature at all — resizing a channel will simply look like depositing into an account, which is exactly the ergonomic endpoint this protocol work has been aiming at.

Splice-in is the capacity-increasing half of channel splicing; its counterpart for withdrawing funds on-chain without closing — paying a bill straight out of channel capital — is covered in our splice-out entry. Both operate on the underlying payment channel funding output, and together they make Lightning channels durable, resizable infrastructure rather than disposable containers.