Splicing: Resizing Lightning Channels Without Closing

Lightning channels have a fundamental constraint: once opened, their capacity is fixed. If a channel holds 0.5 BTC and you need 1 BTC of capacity, the traditional answer is to close the channel, wait for confirmations, and open a new one with the desired amount. That means two on-chain transactions, multiple confirmation periods, and the channel going offline in between. Splicing changes this by allowing you to resize a Lightning channel with a single on-chain transaction while the channel continues to operate.

The Fixed-Capacity Problem

When two nodes open a Lightning channel, they commit a specific amount of bitcoin to a 2-of-2 multisig output on chain. This channel capacity determines the maximum value that can flow through the channel in either direction. Once the funding transaction confirms, the capacity cannot change without closing the channel entirely.

This creates several operational headaches. A routing node that sees high demand on a particular channel cannot increase its capacity without disruption. A merchant receiving more payments than expected cannot expand inbound liquidity on an existing channel. A user who wants to move some funds on chain must close the channel, losing their routing position and any routing fee income from that connection.

Before splicing, operators worked around this with several strategies: loop-in and loop-out via submarine swaps, circular rebalancing, or simply opening additional channels in parallel. Each approach has costs. Submarine swaps require a service provider and incur fees. Circular rebalancing consumes routing fees across multiple hops. Opening parallel channels fragments liquidity and increases the on-chain footprint.

Why not just open more channels? Opening a second channel to the same peer doubles your on-chain footprint without consolidating liquidity. You now have two separate channels to manage, each with its own channel reserve requirements. Splicing achieves the same capacity increase in a single channel, preserving routing table entries and reducing long-term on-chain costs.

What Splicing Does

Splicing modifies a channel's funding transaction while the channel remains open. There are two directions: splice-in adds funds to the channel, and splice-out removes funds from it. In both cases, a new funding transaction replaces the old one on chain, but the channel never goes offline.

Splice-in: adding funds

A splice-in increases channel capacity. The process creates a new funding transaction that spends the existing channel output along with one or more additional UTXOs provided by either channel partner. The new transaction produces a single output: a 2-of-2 multisig with higher value representing the enlarged channel.

Consider a channel between Alice and Bob with 0.5 BTC capacity. Alice wants to add 0.3 BTC. She constructs a splice-in that spends the existing 0.5 BTC channel output plus a 0.3 BTC UTXO from her on-chain wallet. The resulting funding output holds 0.8 BTC, and Alice's local balance increases by 0.3 BTC. Bob's balance remains unchanged.

Splice-out: removing funds

A splice-out decreases channel capacity by moving funds from the channel to an on-chain address. The new funding transaction spends the old channel output and creates two outputs: a smaller channel funding output and a standard output to the destination address.

This effectively replaces the close-then-spend pattern. Instead of closing a channel to access on-chain funds and then opening a new channel, a single splice-out transaction accomplishes both: it sends funds on chain while keeping the channel alive at reduced capacity.

Combined operations

A single splice transaction can combine multiple operations. You can splice in from several UTXOs while simultaneously splicing out to an on-chain address. This enables UTXO consolidation: sweep multiple small on-chain outputs into your channel while extracting funds to a cold storage address, all in one transaction. The result is fewer on-chain UTXOs and better capital efficiency.

How Channel Continuity Works

The most technically interesting aspect of splicing is that the channel never stops working. Payments continue to flow while the splice transaction is unconfirmed. This requires careful protocol design because both the old and new funding transactions are valid simultaneously during the confirmation period.

Dual commitment tracking

After a splice is initiated, both channel parties maintain two sets of commitment transactions: one referencing the original funding output (the pre-splice state) and one referencing the new funding output (the post-splice state). Every HTLC offered or fulfilled during this period is tracked in both commitment sets.

This dual-tracking continues until the splice transaction confirms on chain. Once it has sufficient confirmations, the parties discard the old commitment set and operate solely on the new one. If the splice transaction never confirms (for instance, due to a fee-rate miscalculation), both parties can fall back to the original funding transaction as if the splice never happened.

No downtime, but added complexity: Maintaining parallel commitment states is what makes splicing work without interruption, but it also increases the protocol's complexity. Each pending splice roughly doubles the state that both nodes must track. Multiple concurrent splices multiply this further, which is why implementations typically limit the number of in-flight splice operations.

RBF and fee management

Splice transactions support Replace-By-Fee (RBF), allowing the parties to bump the fee if the initial transaction is not confirming quickly enough. This is important because splice transactions are collaborative: both parties must sign any replacement. The protocol includes mechanisms for either side to propose a fee bump, with the other side co-signing if they agree.

Understanding Bitcoin fee market dynamics matters here. A splice transaction competes for block space like any other on-chain transaction, and during fee spikes, an underpriced splice can remain unconfirmed for extended periods. During this time, the channel operates normally but with the overhead of dual commitment tracking.

Interaction with PSBTs

The splice protocol leverages Partially Signed Bitcoin Transactions (PSBTs) for constructing the splice transaction collaboratively. Each party contributes inputs and outputs to the PSBT, signs their portion, and exchanges signatures. This aligns with the broader trend in Bitcoin toward interactive transaction construction using standardized formats.

Implementation Status

Splicing has moved from theoretical proposal to production implementation across the major Lightning node software projects. The pace of adoption varies, and each implementation has taken a slightly different approach.

CLN: first to ship

Core Lightning shipped splice support in version 23.08, making it the first major implementation to offer the feature in production. CLN's approach exposes splicing through its plugin interface, allowing node operators to trigger splice-in and splice-out operations programmatically. The implementation supports combining multiple splice operations into a single transaction.

Eclair and Phoenix: splicing as architecture

ACINQ took the most aggressive approach to splicing with their Phoenix wallet. Rather than treating splicing as an optional feature, Phoenix rebuilt its entire channel management model around it. Each Phoenix user maintains a single channel to ACINQ's node. When the user needs more inbound capacity or wants to send funds on chain, Phoenix automatically triggers a splice. This eliminates the concept of “channel management” from the user experience entirely.

The tradeoff is that every capacity change requires an on-chain transaction, which means paying mining fees. Phoenix makes this transparent to users by deducting the mining fee from the splice amount. During high-fee periods, small splice operations become proportionally expensive.

LND: work in progress

LND, the most widely deployed Lightning implementation, has been developing splice support as one of its most anticipated features. The LND team has taken a careful approach, focusing on interoperability with the emerging specification and ensuring compatibility with LND's existing channel state machine.

Use Cases

Dynamic channel capacity

The most straightforward use case: adjusting channel size to match demand. A routing node operator can monitor channel utilization and splice in additional funds when a channel consistently routes near its capacity limit. Conversely, underutilized channels can be reduced via splice-out, freeing capital for deployment elsewhere.

UTXO consolidation

Node operators accumulate on-chain UTXOs over time from channel closes, mining rewards, or on-chain payments. Splicing allows consolidating these into an existing channel: a splice-in that consumes multiple inputs. This reduces the operator's UTXO set while simultaneously increasing channel capacity. Compared to a separate consolidation transaction followed by a channel open, this saves one full on-chain transaction.

Replacing submarine swaps

Before splicing, submarine swaps were the primary way to move funds between on-chain and Lightning without closing channels. Loop-in (adding on-chain funds to Lightning balance) and loop-out (moving Lightning funds on chain) each require a swap service, introduce counterparty risk during the swap window, and charge service fees on top of mining fees.

Splicing accomplishes the same economic result with a single collaborative transaction: no intermediary, no service fee, and no trust in a third-party swap provider. The primary remaining advantage of submarine swaps is that they work across different nodes (you can loop funds between channels with different peers), while splicing only modifies a single channel.

On-chain payments from channel funds

Splice-out enables paying an on-chain address directly from Lightning channel funds. A user can pay a Bitcoin address that does not support Lightning without first closing a channel. The channel continues to operate at reduced capacity after the splice confirms.

Liquidity management for routing nodes

Routing node operators spend significant effort on liquidity management. Splicing provides a more direct tool: instead of circular rebalancing (which costs routing fees and may fail) or opening additional channels (which fragments liquidity), operators can resize existing channels to match observed traffic patterns.

Splicing vs. Existing Alternatives

Splicing does not eliminate every existing liquidity tool, but it changes the cost-benefit analysis for each.

Limitations and Tradeoffs

On-chain cost

Every splice requires an on-chain transaction. During high-fee periods, the cost of a splice can be significant, particularly for small adjustments. A splice-in of 100,000 sats during a fee spike might cost 10,000+ sats in mining fees, making it economically questionable. This is the same fundamental constraint that affects all payment channel operations anchored to the Bitcoin base layer.

Confirmation delay

While the channel continues to work during confirmation, the new capacity is not fully settled until the splice transaction confirms. Both parties must maintain dual commitment states during this period. If confirmations take hours or days (common during fee spikes without adequate fee rates), this extended dual-state period increases operational complexity.

Interoperability

Splicing requires both channel parties to support the protocol. You cannot splice a channel unilaterally. If your peer runs software that does not implement splicing, you are stuck with the old close-and-reopen approach. Until all major implementations support splicing in production, this limits its practical availability.

Channel factories interaction

Channel factories are a proposed construction where multiple channels share a single on-chain funding output. Splicing within a channel factory would require coordination among all factory participants, not just the two channel partners. This interaction remains an open area of protocol design.

The Broader Context: Do Channels Need Resizing?

Splicing is a significant improvement to Lightning's channel model, but it is worth considering what problem it solves at a higher level. Channels need resizing because Lightning requires pre-funded, fixed-capacity channels in the first place. Every solution to channel management complexity (splicing, circular rebalancing, loop-in/loop-out, channel factories) exists because of this architectural constraint.

Alternative Layer 2 designs avoid this constraint entirely. Spark, for example, uses a statechain architecture where there are no channels to manage. Users hold funds directly through cooperative key ownership with operators: no channel capacity limits, no inbound liquidity requirements, no splicing needed. A Spark user can receive any amount at any time without worrying about whether a channel is large enough to accommodate the payment.

This is not a criticism of splicing. For the Lightning Network as it exists today, splicing is a genuinely useful improvement that reduces operational friction. But it is instructive that the problem splicing solves (static channel capacity) is an artifact of Lightning's specific architecture rather than an inherent requirement of off-chain Bitcoin payments.

What Comes Next

Specification finalization

The splicing specification is being refined through the BOLT process. Interoperability between implementations is a key milestone: CLN-to-Eclair splicing has been demonstrated, and LND compatibility is the next major target. Full cross-implementation support will make splicing a standard part of Lightning channel lifecycle management.

Integration with other proposals

Splicing interacts with several other Lightning protocol improvements. Taproot channels can benefit from splicing with improved privacy characteristics, since splice transactions can look like ordinary Taproot spends on chain. Eltoo (LN-Symmetry), if activated through a soft fork enabling SIGHASH_ANYPREVOUT, would simplify the dual-commitment tracking required during splice confirmation by allowing state updates to reference any prior funding output.

Zero-conf splicing

Zero-conf splice operations allow the new channel capacity to be used immediately, before the splice transaction confirms. This mirrors zero-conf channel opens: the party providing the funds trusts that the other party will not attempt a double-spend of the splice transaction. Phoenix already uses zero-conf splicing by default, since ACINQ controls both sides of the channel and trusts itself not to double-spend.

Summary

Splicing is one of the most practical improvements to Lightning channel management. It reduces on-chain transactions from two to one when resizing channels, eliminates downtime during the resize, enables direct UTXO consolidation, and can replace submarine swaps for simple on-chain/off-chain fund movements. The tradeoff is protocol complexity: dual commitment tracking, collaborative transaction construction, and the requirement that both peers support the feature.

For Lightning operators and power users, splicing meaningfully reduces the cost and friction of channel management. For everyday users, implementations like Phoenix show how splicing can be abstracted away entirely, turning channel management into an invisible background operation. And for those evaluating the broader Bitcoin Layer 2 landscape, splicing is a reminder that channel-based architectures require ongoing engineering effort to manage the constraints that channels introduce.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.