Splicing

What Is Splicing?

Splicing is a Lightning Network protocol feature that allows participants to modify the funding amount of an existing channel through an on-chain transaction, without ever taking the channel offline. Before splicing, the only way to change a channel's capacity was to close it entirely, wait for the closing transaction to confirm, and then open a new channel with the desired balance. This was expensive, slow, and disruptive.

With splicing, a channel can grow or shrink dynamically. A splice-in adds funds to the channel, increasing its capacity. A splice-out removes funds, sending them to an on-chain address while reducing the channel's capacity. In both cases, the channel continues to route payments throughout the process: there is no interruption, no lost routing slots, and no need to re-establish the channel relationship.

Splicing is defined in the BOLT specifications and represents one of the most significant usability improvements to the Lightning Network since its inception. It bridges the gap between on-chain and off-chain funds, allowing users to treat their Lightning balance and on-chain balance as a single, flexible pool.

How It Works

At its core, a splice replaces the channel's funding transaction. A Lightning channel is anchored by a single on-chain UTXO (the funding output). Splicing creates a new on-chain transaction that spends this funding output and produces a new one with a different amount. The critical innovation is that the channel remains usable during the transition.

Splice-In (Adding Funds)

A splice-in increases the channel's capacity by adding on-chain funds to the funding output:

1. One channel partner initiates a splice request, specifying additional UTXOs to contribute
2. Both parties negotiate and collaboratively construct a new funding transaction that spends the old funding output plus the new inputs
3. Both parties sign new commitment transactions for the updated funding output before signing the splice transaction itself
4. The splice transaction is broadcast to the Bitcoin network
5. While waiting for confirmation, both old and new commitment transaction sets remain valid, and the channel continues operating normally
6. Once confirmed, the old commitment transactions are discarded and the channel operates entirely on the new funding output

Splice-Out (Removing Funds)

A splice-out decreases the channel's capacity, sending funds to an on-chain destination:

1. One party requests a splice-out, specifying the amount and on-chain destination address
2. Both parties construct a splice transaction that spends the old funding output and creates two outputs: a new (smaller) funding output and a regular output paying the on-chain destination
3. New commitment transactions are signed for the reduced funding output
4. The splice transaction is broadcast and the channel continues routing with both old and new states valid
5. After confirmation, the channel operates solely on the smaller funding output

The Transition Period

The most technically challenging aspect of splicing is maintaining channel operation during the transition period between broadcast and confirmation. During this window, both the old funding output (unspent until the splice confirms) and the new funding output coexist. The channel must maintain two parallel sets of commitment transactions:

# Before splice confirms, two valid states exist:

Old funding UTXO (txid: abc...):
  -> Old commitment tx (reflects pre-splice balance)

New funding UTXO (splice tx, txid: def...):
  -> New commitment tx (reflects post-splice balance)

# Both commitment sets update with every new payment
# Once splice tx confirms, old set is discarded

Every new HTLC offered or resolved during this period must be reflected in both commitment transaction sets. This means each payment update requires signing twice as many transactions until the splice confirms. If multiple splices are pending simultaneously, the number of parallel states multiplies further.

Handling Concurrent HTLCs

One of the most complex aspects of splicing is managing HTLCs that are in flight during a splice operation. Consider a channel routing payments while a splice is pending:

• New HTLCs must be added to both the pre-splice and post-splice commitment transactions
• HTLC resolution (fulfillment or failure) must be applied consistently across both states
• The revocation mechanism must work correctly for both commitment transaction sets
• If a force close occurs during the transition, either the old or new funding output will be spent, but not both, and the corresponding commitment transaction must correctly reflect all pending HTLCs

This dual-state tracking is what made splicing one of the more difficult protocol features to implement correctly. Bugs in state synchronization could lead to channel breaches or lost funds, which is why implementations underwent extensive testing before deployment.

Comparison with Close-and-Reopen

Before splicing, the only way to adjust channel capacity was to close the existing channel and open a new one. This approach has significant drawbacks that splicing eliminates:

The fee savings alone make splicing worthwhile. During periods of high on-chain fee markets, closing and reopening a channel could cost tens of dollars. Splicing cuts that cost roughly in half while also eliminating the operational disruption. It also preserves existing channel reserve arrangements, avoiding the reserve negotiation overhead of opening a new channel.

Use Cases

Dynamic Liquidity Management

Node operators can adjust channel sizes in response to routing demand without any downtime (for a deeper exploration, see our research on Lightning Network liquidity). If a channel consistently runs out of outbound liquidity, the operator can splice in additional funds. If a channel is oversized relative to its traffic, funds can be spliced out and deployed elsewhere. This is complementary to techniques like Loop In/Out and circular rebalancing, but operates at the channel capacity level rather than just shifting existing liquidity.

Unified Balance Experience

For end users, splicing enables wallets to present a single balance instead of separating "on-chain" and "Lightning" funds. When a user receives on-chain Bitcoin, the wallet can automatically splice those funds into an existing channel. When a user needs to make an on-chain payment, the wallet can splice out from a channel. The user never needs to understand the distinction between layers.

Phoenix Wallet Implementation

ACINQ's Phoenix wallet is the most prominent real-world implementation of splicing. Phoenix uses a single channel to its node and relies heavily on splicing to manage that channel's capacity:

• Receiving on-chain payments triggers an automatic splice-in, adding the funds to the user's Lightning channel
• Sending on-chain payments uses splice-out, paying the destination directly from the channel's funding output
• Inbound liquidity is managed through splicing combined with zero-conf channels, allowing instant usability even before the splice confirms
• The user sees a single balance and can send to any Bitcoin address or Lightning invoice without manual channel management

This approach demonstrates how splicing, combined with other techniques, can make the Lightning Network transparent to end users. The complexity of channel management is entirely abstracted away.

Channel Factories and Multiparty Channels

Splicing is a building block for more advanced constructions like channel factories. In a channel factory, multiple parties share a single funding UTXO that contains several channels. Splicing allows individual channels within the factory to be resized without affecting the others, making the factory more flexible and practical.

Risks and Considerations

On-Chain Fee Exposure

Every splice requires an on-chain transaction, which means paying miner fees. During high-fee environments, frequent splicing can become expensive. Users and wallet implementations must weigh the cost of a splice against the benefit of the capacity change. Batching multiple splice operations into a single transaction can help reduce costs.

Confirmation Time

Until the splice transaction confirms, the channel operates in a dual-state mode. While this does not affect functionality, it increases the computational and storage overhead for both channel partners. Long confirmation delays (due to low fee rates or network congestion) extend this overhead period.

Some implementations combine splicing with zero-conf trust assumptions, allowing the new capacity to be used immediately. This introduces counterparty risk: if the splice transaction is double-spent before confirming, the channel state becomes invalid. This tradeoff is acceptable between trusted partners (such as a user and their wallet provider) but not suitable for arbitrary peers.

Implementation Complexity

Splicing is one of the more complex protocol features to implement correctly. The dual-state commitment tracking, concurrent HTLC management, and interaction with other protocol features (like anchor outputs) create a large surface area for bugs. Incorrect implementations could lead to channel breaches, stuck channels, or loss of funds.

Privacy Implications

Splice transactions are visible on-chain and reveal that a Lightning channel is being resized. Chain analysis can potentially link the old and new funding outputs, track channel capacity changes over time, and correlate splice-outs with on-chain payments. Users concerned about privacy should be aware that splicing creates on-chain footprints that purely off-chain operations like circular rebalancing do not.