Splice-In

What Is a Splice-In?

A splice-in is a specific type of splicing operation on the Lightning Network that increases the capacity of an existing payment channel by adding new on-chain funds. Where splicing is the general concept of resizing a channel (either up or down), a splice-in refers specifically to the "adding funds" direction.

Before splicing existed, the only way to increase a channel's capacity was to close it entirely, wait for the closing transaction to confirm, and then open a new, larger channel. This required two on-chain transactions, caused hours or days of downtime, and destroyed the channel's routing reputation in the network graph. A splice-in accomplishes the same goal with a single on-chain transaction and zero downtime.

The operation works by constructing a new funding transaction that spends the channel's existing funding output alongside one or more additional UTXOs contributed by the party adding funds. The result is a new, larger 2-of-2 multisig output that becomes the channel's updated anchor on the Bitcoin blockchain.

How It Works

A splice-in follows a structured protocol negotiation between the two channel partners. The process reuses the interactive transaction construction protocol originally designed for dual-funded channels, ensuring consistency across Lightning's on-chain coordination mechanisms.

Step-by-Step Process

1. The initiating peer sends a quiescence message (stfu) to pause the channel's state machine, and the other peer responds with its own stfu to confirm the pause
2. The initiator sends a splice_init message specifying the amount of funds to add, and the peer replies with splice_ack if it agrees to proceed
3. Both peers enter interactive transaction construction, exchanging tx_add_input and tx_add_output messages to build the splice transaction collaboratively
4. The initiator contributes an input spending the current funding output plus one or more UTXOs containing the additional funds
5. Both peers sign new commitment transactions for the updated funding output before signing the splice transaction itself
6. The splice transaction is broadcast to the Bitcoin network, and both peers exit quiescence to resume normal channel operation

Parallel Commitment States

The most technically significant aspect of a splice-in is what happens between broadcast and confirmation. During this window, both the original funding output and the new (larger) funding output coexist on the blockchain. The channel must maintain two parallel sets of commitment transactions:

# During the confirmation window, two valid states coexist:

Old funding UTXO (0.5 BTC):
  -> Old commitment tx (pre-splice balances)

New funding UTXO (splice tx, 0.8 BTC):
  -> New commitment tx (post-splice balances)

# Every payment update is applied to BOTH sets
# Once the splice tx confirms, old set is discarded

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

There is one important restriction during the confirmation window: the party that spliced in funds cannot use those newly added funds to offer HTLCs until the splice transaction confirms. Only funds that existed in the channel before the splice can be used for routing during this period.

Worked Example

Consider a channel between Alice and Bob with 0.5 BTC total capacity, where Alice holds 0.3 BTC and Bob holds 0.2 BTC. Alice wants to add 0.3 BTC from her on-chain wallet:

1. Alice constructs a splice-in that spends the existing 0.5 BTC channel funding output plus a 0.3 BTC UTXO from her on-chain wallet
2. The resulting funding output holds 0.8 BTC in a new 2-of-2 multisig
3. Alice's in-channel balance increases from 0.3 BTC to 0.6 BTC
4. Bob's balance remains unchanged at 0.2 BTC
5. The channel's total capacity grows from 0.5 BTC to 0.8 BTC

Throughout this process, Alice and Bob continue routing payments through the channel. The only on-chain cost is the mining fee for the single splice transaction.

Splice-In vs. Opening a New Channel

Before splicing, operators who needed more capacity on an existing route had two options: close and reopen the channel with more funds, or open a second parallel channel to the same peer. Both approaches have significant drawbacks that splice-in eliminates:

The parallel channel approach avoids downtime but introduces liquidity fragmentation: routing algorithms must now choose between two smaller channels instead of using one large one. Splice-in combines the best of both worlds by keeping a single, larger channel with preserved history.

Use Cases

Wallet-Level Channel Management

ACINQ's Phoenix wallet is the most prominent real-world implementation of splice-in operations. Phoenix maintains exactly one channel per user and relies on splicing for all capacity adjustments. When a user receives on-chain Bitcoin, Phoenix automatically triggers a splice-in to add those funds to the channel. The user sees a single unified balance rather than separate on-chain and Lightning balances.

This approach, combined with zero-conf trust assumptions between the user and ACINQ's node, allows instant usability of spliced-in funds even before the splice transaction confirms on-chain.

Routing Node Liquidity Scaling

Routing node operators use splice-ins to respond to demand without disrupting their routing graph. If a channel consistently runs out of outbound liquidity, the operator can splice in additional funds rather than closing and reopening at a larger size. This preserves the channel's position in pathfinding algorithms and avoids the reputation penalty of appearing as a new, untested channel (for a deeper exploration, see our research on Lightning Network liquidity).

Gradual Capital Deployment

Splice-ins allow operators to start channels small and grow them incrementally based on actual traffic. Rather than committing a large amount of capital upfront to a channel that may not justify it, an operator can open a modest channel and splice in more funds as routing volume proves the channel's value. This reduces the opportunity cost of capital locked in underutilized channels.

Consolidating On-Chain Funds

A splice-in can consume multiple on-chain UTXOs as inputs, effectively consolidating them while simultaneously adding funds to a channel. This combines two operations (UTXO consolidation and capacity increase) into a single on-chain transaction, saving on fees compared to performing them separately.

Why It Matters

Splice-in operations represent a fundamental shift in how Lightning channels interact with on-chain Bitcoin. Before splicing, channels were static containers: once opened, their capacity was fixed for their entire lifetime. This rigidity forced operators into inefficient patterns of closing and reopening channels, wasting on-chain block space and fragmenting network liquidity.

With splice-ins, channels become dynamic. They can grow organically in response to demand, absorb on-chain deposits seamlessly, and maintain continuous uptime through capacity changes. This is especially important for the user experience in mobile wallets, where channel management complexity should be invisible (for a broader look at how splicing fits into Lightning's evolution, see our research on splicing Lightning channels).

For platforms like Spark, which aim to simplify Bitcoin's layer-2 experience, splice-in mechanics inform the design of fund management systems that abstract away the complexity of channel operations entirely.

Risks and Considerations

On-Chain Fee Exposure

Every splice-in requires an on-chain transaction, which means paying mining fees at the prevailing fee rate. During periods of high network congestion, splicing can become expensive. Wallet implementations must weigh the cost of a splice against the benefit of the capacity increase and may choose to batch multiple small deposits into a single splice operation.

Confirmation Delay

Until the splice transaction confirms, the channel operates in dual-state mode with parallel commitment transactions. This increases computational and storage overhead for both channel partners. Long confirmation delays due to low fee rates or network congestion extend this overhead period and prevent the initiator from using spliced-in funds for new HTLCs.

Implementation Complexity

Splice-in is one of the more complex protocol features to implement correctly. Managing parallel commitment states, ensuring consistent HTLC handling across both transaction sets, and coordinating with other protocol features like anchor outputs and channel reserves creates a significant surface area for bugs. Incorrect implementations could lead to channel breaches, stuck channels, or loss of funds.

Privacy Considerations

Splice-in 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 capacity changes over time, and identify which additional UTXOs were consumed. Users concerned about privacy should note that splicing creates on-chain footprints that purely off-chain operations do not.

Interoperability

Both channel partners must support splicing for a splice-in to occur. The feature is negotiated via Lightning's feature-bit system during connection setup. While splicing has been standardized in the BOLT specifications and is supported in Eclair, Core Lightning, and LDK, adoption is not yet universal across all Lightning implementations. If your channel partner's node does not support splicing, a splice-in is not possible on that channel.

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.