Splicing vs Submarine Swaps: Lightning Channel Management

Splicing vs Submarine Swaps: Overview

Managing Lightning channels has always been one of the hardest parts of running a Lightning node or wallet. Channels need the right balance of inbound and outbound capacity, and moving funds between on-chain and off-chain without closing channels requires specialized techniques. Two approaches dominate: splicing and submarine swaps.

Splicing modifies a channel's funding transaction in place, adding or removing capacity without closing the channel. Submarine swaps use HTLCs to atomically exchange on-chain bitcoin for off-chain Lightning balance (or vice versa) through a swap provider, leaving channel capacity unchanged.

Both are trustless and both require on-chain transactions, but they differ in cost structure, privacy properties, wallet support, and the problems they solve. The following table summarizes the key differences.

How Splicing Works

A splice-in adds funds to an existing channel by creating a new funding transaction that spends the old one plus additional on-chain inputs. A splice-out removes funds by creating a new funding transaction with a smaller channel output and a separate output sent to an on-chain address. In both cases, both channel peers cooperatively sign the new funding transaction.

The channel remains operational throughout the process. While the splice transaction awaits confirmation, both the old and new channel states are valid, so payments continue to flow. Once confirmed, the old state is discarded and the channel operates at its new capacity.

Phoenix Wallet pioneered production splicing in 2023 by rebuilding its architecture around a single dynamic channel per user. Instead of opening new channels when capacity is needed, Phoenix splices the existing channel. On-chain receives trigger a splice-in, and on-chain sends use a splice-out. The previous 1% inbound liquidity fee was replaced by the miner fee for the underlying splice transaction.

How Submarine Swaps Work

A submarine swap is an atomic exchange between on-chain and off-chain bitcoin. In a standard (forward) swap, the user locks on-chain funds in an HTLC script. The swap provider then pays the user's Lightning invoice, revealing the hash preimage. The provider uses that preimage to claim the on-chain funds. The HTLC ensures the swap either completes fully or is refunded after a timelock expires.

A reverse swap runs in the opposite direction: the user sends a Lightning payment to the provider, who locks on-chain funds in an HTLC. The user claims the on-chain output using the preimage. This is how Loop Out works: it converts Lightning balance into on-chain bitcoin, freeing up inbound capacity.

Major swap providers include Lightning Labs' Loop (integrated with LND and Lightning Terminal) and Boltz Exchange (non-custodial, implementation-agnostic). Electrum also supports running a swap server for users who want to self-host.

Cost Comparison

Cost is where the two approaches diverge most sharply. Splicing has no service fee: users pay only the on-chain miner fee for the splice transaction. Submarine swaps add a percentage-based service fee on top of on-chain and routing fees.

At low fee rates (5 sat/vB), splicing is roughly 2x to 5x cheaper than a submarine swap for the same amount. During fee spikes, the gap narrows because miner fees dominate both approaches, but the service fee on swaps still adds up for larger amounts. For a deeper look at channel economics, see the Lightning channel cost calculator.

Speed and Confirmation

Both splicing and submarine swaps require one on-chain transaction, so both are gated by block confirmations. The difference is what happens while waiting.

With splicing, the channel stays fully operational during confirmation. Payments route normally through the old channel state until the splice confirms, at which point the channel transitions to its new capacity. This is possible because both the pre-splice and post-splice commitment transactions remain valid until confirmation.

With submarine swaps, the Lightning payment completes instantly (or within seconds), but the on-chain leg must confirm before funds are available. For a Loop In, the user's Lightning balance increases immediately, but the on-chain HTLC needs confirmation. For a Loop Out, the on-chain output needs confirmation before the user can spend those funds.

Privacy Considerations

The two approaches have different privacy properties that matter for users concerned about on-chain surveillance.

Submarine swaps introduce a layer of separation between the user's on-chain identity and their Lightning activity. The on-chain HTLC is between the user and the swap provider, not directly linked to the user's channel. The recipient of an on-chain payment via a reverse swap sees only the swap provider's UTXO, not the sender's. This makes swaps useful for breaking the link between on-chain UTXOs and Lightning node identity.

Splicing, by contrast, directly modifies the channel's funding output. An observer watching the blockchain can see the splice transaction and link it to the channel. However, splicing has its own privacy advantages: LSPs can batch multiple users' funds into a single splice transaction, which disrupts common input ownership heuristics used by chain analysis tools. Some implementations also support combining splices with CoinJoin-style techniques.

Wallet and Implementation Support

Submarine swaps have broader implementation support because they work with any Lightning node that supports standard HTLCs. Splicing requires protocol-level support from both channel peers.

A critical constraint: both channel peers must run splicing-compatible software. If your peer's node doesn't support splicing, you fall back to submarine swaps or closing and reopening the channel. This interoperability requirement slows real-world adoption even after implementations ship the feature.

When to Use Each Method

Choosing between splicing and submarine swaps depends on what problem you are solving and which tools your node supports.

Use splicing when:

• You need to increase or decrease total channel capacity
• You want to send or receive on-chain without closing a channel
• You want to minimize fees (no service fee, miner fee only)
• You want to consolidate UTXOs into your channel funding output
• Both you and your channel peer support splicing

Use submarine swaps when:

• You need to shift balance within a channel without changing capacity
• You want to acquire inbound liquidity without a new channel
• Your node runs LND (which has native Loop support but limited splicing)
• You want to break the on-chain link between your UTXOs and your channel
• You need to move funds between on-chain and Lightning with a counterparty who doesn't share a channel with you

Decision Flowchart

Start with the core question: do you need to change your channel's total capacity, or just its balance?

1. Need more total capacity (bigger channel)? Use splice-in. If your peer doesn't support splicing, open an additional channel.
2. Need to reduce total capacity (withdraw funds on-chain)? Use splice-out. If unavailable, use a reverse submarine swap (Loop Out).
3. Need more inbound liquidity (same capacity, different balance)? Use a submarine swap (Loop Out) to push local balance on-chain and free up inbound. Alternatively, use circular rebalancing if you have multiple channels.
4. Need to receive on-chain funds into Lightning? Splice-in is cheaper. If your node doesn't support it, use a swap-in (Loop In) or swap-in-potentiam.
5. Privacy is the priority? Submarine swaps provide better separation between on-chain UTXOs and your Lightning node identity.

Limitations of Both Approaches

Neither splicing nor submarine swaps solves the fundamental complexity of Lightning channel management. Both require on-chain transactions (and therefore miner fees and confirmation delays). Both require the user to understand concepts like channel capacity, channel balance, and outbound versus inbound liquidity. Submarine swaps add counterparty fees. Splicing adds peer compatibility requirements.

For a broader view of scaling solutions that take different architectural approaches, see our Bitcoin second-layer scaling landscape overview.

The Channel-Free Alternative

Spark is a Bitcoin Layer 2 built on statechains that removes channels from the equation entirely. Instead of managing channel capacity and balance, Spark transfers UTXO ownership off-chain through cooperative key rotation among a threshold set of FROST signers. There is no channel to splice, no balance to rebalance, and no swap provider to pay. Spark-to-Spark transfers settle in under a second with no routing fees.

This architectural difference means users never encounter the liquidity management problems that splicing and submarine swaps exist to solve. For users who want to hold and transfer bitcoin (or USDB stablecoins) without learning channel mechanics, Spark offers a fundamentally simpler model. For a direct comparison, see why Spark's channel-free design matters for UX.

Frequently Asked Questions

What is splicing in Lightning Network?

Splicing is a protocol feature that lets you add funds to (splice-in) or remove funds from (splice-out) an existing Lightning channel without closing it. Both channel peers cooperatively sign a new funding transaction that replaces the old one. The channel remains operational throughout the process, continuing to route payments while the splice transaction confirms on-chain.

What is a submarine swap?

A submarine swap is a trustless, atomic exchange between on-chain bitcoin and Lightning Network balance. It uses an HTLC to ensure that either both legs of the swap complete or neither does. A forward swap converts on-chain funds to Lightning balance. A reverse swap converts Lightning balance to on-chain funds. Swap providers like Loop and Boltz facilitate these exchanges for a service fee.

Is splicing cheaper than submarine swaps?

Yes, in most cases. Splicing has no service fee: you pay only the on-chain miner fee for the splice transaction. Submarine swaps charge a service fee (typically 0.1% to 1% depending on the provider and direction) plus on-chain miner fees and Lightning routing fees. For a 1,000,000 sat operation at moderate fee rates, splicing can cost 2x to 5x less than a submarine swap.

Does LND support splicing?

As of late 2026, LND has experimental splicing support in development but has not shipped production-ready splicing. Core Lightning (since v23.08), Eclair/Phoenix, and LDK all support splicing in production. LND users can use Lightning Labs' Loop service for submarine swaps as an alternative for managing channel liquidity.

Can I use splicing and submarine swaps together?

Yes. They solve different problems and can complement each other. Use splicing to resize channels (change total capacity) and submarine swaps to rebalance existing channels (shift the inbound/outbound ratio without changing capacity). A node operator might splice-in to grow a channel with a well-connected peer, then use Loop Out to push balance toward that peer and increase inbound capacity on other channels.

Do submarine swaps require trust?

No. Submarine swaps are atomic: the on-chain HTLC and the Lightning payment are linked by the same hash preimage. If the swap provider claims the on-chain funds, the preimage is revealed, which proves the Lightning payment was made. If the provider fails to pay the Lightning invoice, the on-chain funds return to the sender after the timelock expires. No trust in the swap provider is required for the exchange itself.

Which is better for privacy: splicing or submarine swaps?

Submarine swaps generally offer better on-chain privacy because the swap provider acts as an intermediary. The recipient of a reverse swap sees the provider's UTXO, not the sender's, breaking the direct link between on-chain funds and Lightning identity. Splicing directly modifies the channel's funding output, making the connection between on-chain UTXOs and the channel visible to chain analysis. However, batched splicing by LSPs can disrupt common input ownership heuristics.

This tool is for informational purposes only and does not constitute financial advice. Fee ranges are approximate and based on publicly available information from provider documentation. Actual costs vary with network conditions, provider pricing changes, and transaction complexity. Always check current fee schedules with your swap provider or node implementation before making decisions.