Splice-Out

What Is a Splice-Out?

A splice-out is a channel splicing operation that withdraws funds from a Lightning Network channel to any on-chain Bitcoin address. Unlike a cooperative close, which shuts down the entire channel, a splice-out keeps the channel open and functional with a reduced capacity.

Before splicing existed, the only ways to move Lightning funds on-chain were to close the channel entirely or use a third-party swap service. Closing a channel is disruptive: it eliminates routing capacity, requires opening a new channel later, and costs two on-chain transactions (close plus reopen). Splice-out solves this by letting channel peers resize the channel in place with a single on-chain transaction.

The feature was standardized as part of the BOLT specification for Lightning and first deployed in production by Phoenix Wallet (built on Eclair) and Core Lightning in 2024. LDK added splice-out support in 2025, broadening availability across the Lightning ecosystem.

How It Works

A splice-out modifies the channel's funding transaction on-chain while preserving the off-chain payment capability. Here is the step-by-step process:

1. One peer initiates the splice by signaling their intent to remove funds from the channel
2. Both peers enter a quiescence state (using the STFU protocol message), temporarily pausing new HTLC forwarding to ensure a clean splice
3. The initiator sends a splice_init message specifying the amount to remove, and the peer responds with splice_ack
4. Both sides collaboratively construct a new transaction using the interactive transaction protocol, exchanging inputs and outputs
5. The new transaction spends the existing funding output and creates two outputs: a new (smaller) funding output for the channel and an additional output sending funds to the desired on-chain address
6. Both peers exchange commitment signatures for the new channel state, then exchange transaction signatures to finalize the splice transaction
7. The splice transaction is broadcast to the Bitcoin network for confirmation
8. Once confirmed, both peers send splice_locked messages and transition fully to the new channel state

Channel Continuity During Splicing

A critical design feature of splicing is that the channel remains usable while the splice transaction is unconfirmed. Both the old and new channel states are valid simultaneously during this period. Peers maintain commitment transactions for both states, and payments can continue to flow through the channel without interruption.

This dual-state approach means that a splice-out does not force any downtime. From the perspective of the rest of the Lightning Network, the channel never goes offline. Once the splice transaction reaches sufficient confirmations, the old state is retired and only the new, smaller channel remains active.

Transaction Structure

The splice-out transaction looks similar to a standard Bitcoin transaction with one key difference: its input is the channel's existing funding output (a 2-of-2 multisig), and it produces a new 2-of-2 multisig output as the updated funding output. A simplified view:

Splice-Out Transaction
─────────────────────────────────────────
Input:
  - Previous funding output (2-of-2 multisig, e.g. 0.5 BTC)

Outputs:
  - New funding output (2-of-2 multisig, e.g. 0.35 BTC)
  - On-chain destination address (e.g. 0.15 BTC minus fees)

Result:
  - Channel capacity reduced from 0.5 BTC to 0.35 BTC
  - 0.15 BTC (minus miner fees) sent to on-chain address
  - Channel remains open and operational

Either peer can contribute additional inputs if needed, for example to cover transaction fees. The interactive transaction protocol handles this negotiation. If the splice transaction needs a fee bump after broadcast, it must be done via RBF rather than CPFP, since splice outputs may carry spending restrictions.

Splice-Out vs. Other Lightning-to-On-Chain Methods

Several methods exist for converting Lightning funds to on-chain Bitcoin. Each involves different tradeoffs around capacity, cost, and trust:

The fundamental distinction is that splice-out changes channel capacity, while submarine swaps preserve it. With a submarine swap, a swap service effectively takes your Lightning payment and sends you an on-chain transaction (or vice versa), so your channel balance shifts but the total capacity stays the same. A splice-out physically resizes the channel, meaning you will have less routing capacity afterward. For a deeper comparison, see the splicing research article.

Use Cases

Withdrawing to Cold Storage

A routing node operator who has accumulated profits in their channels can splice out a portion directly to a cold storage address. This avoids closing any channels, preserving the node's routing graph position and existing peer connections.

Paying On-Chain Invoices

When a user needs to make an on-chain payment but their funds are in Lightning channels, a splice-out sends funds directly to the recipient address. This is more capital-efficient than closing a channel, paying the invoice, and then opening a new channel.

Right-Sizing Channel Capacity

Over time, a channel may become over-provisioned relative to its routing traffic. Splice-out lets operators reduce capacity on underutilized channels and redeploy that capital elsewhere, either on-chain or through splice-in operations on busier channels.

Seamless Wallet Experience

Mobile wallets like Phoenix use splicing to provide a unified balance experience. When a user wants to send an on-chain payment, the wallet performs a splice-out behind the scenes, making the distinction between on-chain and Lightning funds transparent to the user.

Risks and Considerations

Capacity Reduction

The most immediate tradeoff of a splice-out is reduced channel capacity. If you frequently route payments through the affected channel, the lower capacity may cause payment failures. If you later need to restore capacity, you will need to perform a splice-in, which requires another on-chain transaction and its associated fees.

On-Chain Fees

Every splice-out requires an on-chain transaction, so the cost depends on the current Bitcoin fee market. During periods of network congestion, a splice-out can be expensive. Unlike submarine swaps, which have a flat percentage-based fee that is predictable, splice-out costs fluctuate with block space demand.

Confirmation Delay

While the channel remains operational during the splice, the on-chain recipient must wait for the splice transaction to confirm before they can spend the funds. This is no different from any other on-chain payment, but it means the withdrawal is not instant from the recipient's perspective.

Implementation Support

Splicing is still maturing across the Lightning ecosystem. As of 2026, CLN, Eclair (Phoenix), and LDK support splice-out, but LND has not yet shipped full splicing support. Both channel peers must run compatible implementations for a splice to work, which limits availability depending on who you have channels with.

Fee Bumping Constraints

If a splice transaction gets stuck in the mempool due to low fees, it must be fee-bumped via replace-by-fee (RBF). Standard CPFP fee bumping may not be available because splice outputs can carry spending restrictions. Operators should set appropriate initial fee rates to avoid stuck transactions.

Why It Matters

Splice-out is part of a broader trend toward making Lightning channels flexible, long-lived infrastructure rather than static, fixed-capacity pipes. Combined with splice-in (adding funds to a channel), splicing allows channels to be resized dynamically in response to changing liquidity needs, all without disrupting payment routing.

For end users, splicing eliminates the sharp boundary between on-chain and Lightning funds. Wallets can present a single balance and seamlessly route withdrawals through splices, swaps, or direct payments depending on what is most efficient. For node operators, splice-out provides a capital management tool that avoids the costly close-and-reopen cycle. For a broader look at how channel management tools fit together, see the channel management research article.

Layer 2 solutions like Spark take a different architectural approach that avoids channels entirely, using virtual UTXOs instead. This design sidesteps the need for splicing by not tying user funds to fixed-capacity channels in the first place.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.