Closing a Lightning channel to resize it has always been the annoying part of running a Lightning node. You wait for a mutual close, wait again for a new funding transaction to confirm, and lose routing capacity on that path the whole time. Channel splicing removes that wait. It lets you add or remove on-chain funds from a channel that stays open the entire time, with no interruption to pending payments on other channels and no loss of the channel’s routing history. As of October 12, 2026, splicing has shipped in some Lightning implementations and is still missing from others, which makes it one of the more confusing features to get working correctly on your first try. This tutorial walks through building a test lab, running real splice-in and splice-out operations with Core Lightning, batching multiple splices into one transaction, and automating the whole process with a Python script.

What Channel Splicing Actually Changes

A standard Lightning channel is backed by a single funding transaction on the Bitcoin blockchain. Once that transaction confirms, the channel’s capacity is fixed until you close it. If you want more capacity, the old workflow was to close the channel cooperatively, wait for the closing transaction to confirm, then open a brand new channel with a new funding transaction. That process can take anywhere from ten minutes to several hours depending on mempool conditions, and the channel is completely unusable for routing while it happens.

Splicing replaces the single funding transaction with a new one while keeping the channel’s short channel ID, its HTLC history, and its place in the routing graph intact in most implementations. A splice-in transaction adds satoshis from an on-chain wallet into the channel. A splice-out transaction removes satoshis from the channel balance and sends them to an address, back to the wallet, or directly into a different channel with the same or a different peer. The mechanism behind this is interactive transaction construction, a process defined for channel funding that both peers use to jointly build, sign, and broadcast the new funding transaction without either side needing to trust the other with its private keys.

Because splicing reuses interactive transaction construction, the new funding transaction can be dual-funded. Both peers can contribute inputs to the same splice, which matters if a routing node operator wants a peer to add liquidity on their side of a channel at the same time the operator tops up their own side. The specification for channel splicing was merged into the BOLT repository as pull request #1160, titled Channel Splicing (feature 62/63), on March 23, 2026, after 262 comments of review. That merge gave implementation teams a stable target to code against, which is part of why support has moved quickly since early 2026 even though the underlying idea had been discussed in the Lightning developer community for years before that.

None of this makes splicing free. The new funding transaction still needs miner fees, and a splice-out still needs a confirmed output somewhere. What splicing actually buys you is continuity. The channel keeps routing while the splice transaction sits unconfirmed in the mempool, and most implementations let you keep using the channel’s current balance during that window through a mechanism called quiescence, which freezes new HTLCs just long enough to swap in the new commitment state once the splice confirms.

Prerequisites: Software, Versions, and Network Requirements

This tutorial uses Core Lightning (CLN) because it currently has the most complete and best-documented splicing RPC surface of any implementation still actively shipping new splice features. You will need:

  • Core Lightning v26.06 or later, compiled with the --experimental-dual-fund startup flag enabled. Splicing has not yet graduated out of experimental status in CLN as of the v26.06.9 release.
  • Bitcoin Core (any current version) running in regtest mode, or a signet/testnet node if you want to test with real network latency.
  • Two CLN nodes you control, or one CLN node and access to a peer willing to splice with you on signet.
  • Python 3.10 or later for the automation script in the final section.
  • Basic comfort with the lightning-cli command line tool and JSON-RPC responses.

If you plan to test against a peer running a different implementation, check compatibility first. Eclair shipped what its release notes call the final version of channel splicing in v0.14.0 on May 21, 2024, making it the most battle-tested splicing implementation in production today. LDK added splicing support in its v0.2 release on December 2, 2025, with the project’s own changelog noting it was expected to interoperate with Eclair and future CLN versions. LND, despite being the most widely deployed implementation on the network, has not shipped splicing as of its v0.21.4-beta release on October 1, 2026. LND’s v0.21.0 release in June 2026 added taproot channel optimizations the release notes describe as laying the groundwork for splice support, but the feature itself is still absent from the client most routing nodes run.

Keep that implementation gap in mind through the rest of this guide. Everything demonstrated here with CLN-to-CLN splicing will work the same way between CLN and Eclair or CLN and LDK. It will not work against an LND peer until that project ships its own splicing code.

If you have never run a Lightning node before, splicing is not the place to start. Get comfortable opening and closing plain channels first, ideally by working through a basic Lightning Network node setup or a dedicated LND node walkthrough before attempting anything that touches an existing channel’s funding transaction. Splicing assumes you already know how to read channel state output, restart a stuck daemon, and recover from a disconnected peer, since every one of those skills comes up during a splice that does not go perfectly on the first try.

Step 1-3: Build a Regtest Lab for Splicing

Testing splices against real mainnet funds is a bad idea the first few times you try it. Build a local regtest environment instead, where you control block generation and can replay a failed splice as many times as you need.

Step 1: Install Bitcoin Core and Core Lightning

Install the latest stable Bitcoin Core release and Core Lightning from your distribution’s package manager, from source, or from the project’s prebuilt binaries. On Debian or Ubuntu-based systems, compiling CLN from source with the experimental dual-funding flag enabled looks like this:

git clone https://github.com/ElementsProject/lightning.git
cd lightning
git checkout v26.06.9
./configure --enable-developer
make -j$(nproc)
sudo make install

Confirm the install worked and check which splice-related RPC commands your build exposes:

lightningd --version
lightning-cli help | grep -i splice

A build with dual-funding compiled in should list splice_init, splice_update, splice_signed, splicein, spliceout, and splice as the result of that grep. The first three are low-level primitives used for manual interactive transaction construction. The last three are high-level convenience commands that wrap that negotiation into a single call, and that is what most of this tutorial uses.

Step 2: Start bitcoind in regtest mode and fund two CLN wallets

bitcoind -regtest -daemon -fallbackfee=0.0001
bitcoin-cli -regtest createwallet "splicetest"
bitcoin-cli -regtest generatetoaddress 110 $(bitcoin-cli -regtest getnewaddress)

lightningd --network=regtest --experimental-dual-fund --daemon --lightning-dir=~/.lightning-a
lightningd --network=regtest --experimental-dual-fund --daemon --lightning-dir=~/.lightning-b

bitcoin-cli -regtest sendtoaddress $(lightning-cli --lightning-dir=~/.lightning-a newaddr | jq -r .bech32) 5
bitcoin-cli -regtest generatetoaddress 6 $(bitcoin-cli -regtest getnewaddress)

Generating 110 blocks on a fresh regtest chain clears the coinbase maturity window so your funds are spendable immediately. Fund node A with 5 regtest BTC and confirm it with six more blocks before moving on.

Step 3: Open a baseline channel between the two nodes

NODE_B_ID=$(lightning-cli --lightning-dir=~/.lightning-b getinfo | jq -r .id)
lightning-cli --lightning-dir=~/.lightning-a connect [email protected]:19736
lightning-cli --lightning-dir=~/.lightning-a fundchannel $NODE_B_ID 1000000
bitcoin-cli -regtest generatetoaddress 6 $(bitcoin-cli -regtest getnewaddress)

That opens a 1,000,000-satoshi channel, which is the channel you will splice in the rest of this walkthrough. Six confirmations are more than CLN needs for a regtest channel to become usable, but matching mainnet confirmation depth habits here avoids surprises later.

Step 4-5: Confirm Splice Support Between Peers

Splicing is negotiated per channel, which means both sides of a channel must advertise and accept the splicing feature bit before either side can initiate one. Check the channel’s feature negotiation before attempting a splice, because a failed feature check produces a confusing peer-level error rather than a clean splice-specific one.

lightning-cli --lightning-dir=~/.lightning-a listpeerchannels $NODE_B_ID | jq '.channels[0].features'

Look for feature bit 62 or 63 in the output, the same bit pair referenced in BOLT pull request #1160. If neither bit appears, double check that both nodes were started with --experimental-dual-fund and that you are running v26.04 or later, since that is the release where the high-level splicein and spliceout commands were added to CLN. If you are testing against an Eclair or LDK peer instead, confirm Eclair is on v0.14.0 or later or LDK is on v0.2 or later, since earlier releases of both projects either lack splicing entirely or only support early draft versions of the specification that will not negotiate cleanly with the finalized BOLT text.

Step 6-7: Perform a Splice-In to Add On-Chain Liquidity

A splice-in takes funds from the initiating node’s on-chain wallet and adds them to an existing channel’s capacity. This is the operation you will reach for most often, typically when a channel keeps running low on outbound liquidity and you would rather top it up than open a second channel with the same peer.

CHANNEL_ID=$(lightning-cli --lightning-dir=~/.lightning-a listpeerchannels $NODE_B_ID | jq -r '.channels[0].channel_id')

lightning-cli --lightning-dir=~/.lightning-a splicein $CHANNEL_ID 500000

That command pulls 500,000 satoshis out of node A’s wallet and adds it to the channel, returning a PSBT, the final signed transaction in hex, and a transaction ID in the response. The transaction still needs to confirm before the new capacity is considered final, so generate a block on regtest and check the channel again:

bitcoin-cli -regtest generatetoaddress 1 $(bitcoin-cli -regtest getnewaddress)
lightning-cli --lightning-dir=~/.lightning-a listpeerchannels $NODE_B_ID | jq '.channels[0].total_msat'

Expect the output to show roughly 1,500,000,000 millisatoshis of total channel capacity, up from the original 1,000,000,000, minus whatever on-chain fee the splice transaction paid. On regtest with the default fallback fee, that difference will be small. On mainnet it depends entirely on the fee rate you set, which is covered in Step 10.

Step 8-9: Perform a Splice-Out to Withdraw Funds

A splice-out does the opposite: it removes satoshis from a channel’s balance and sends them somewhere else, without closing the channel. The destination can be your own on-chain wallet, an external bitcoin address, or another channel entirely, which CLN’s documentation refers to as a cross-splice.

lightning-cli --lightning-dir=~/.lightning-a spliceout $CHANNEL_ID 200000

# Or send the withdrawn funds to a specific address instead of the wallet:
lightning-cli --lightning-dir=~/.lightning-a spliceout $CHANNEL_ID 200000 \
  destination=bcrt1qexampleaddressgoeshere

The fee for a splice-out transaction is taken out of the channel’s own funds rather than the wallet, since the whole point of the operation is to move money out of the channel in the first place. If the calculated fee rate looks unreasonably high relative to current network conditions, CLN will refuse the splice by default as a safety check. You can override that check by passing force_feerate=true, but do that deliberately and only after confirming the fee estimate yourself, since skipping the safety check is exactly the kind of thing that turns a routine liquidity rebalance into an expensive mistake.

Confirm the splice-out the same way as the splice-in, by generating a block and re-checking the channel’s capacity. It should now sit roughly 200,000 satoshis lower than it was after Step 7, again minus the on-chain fee the transaction paid.

Step 10: Fee-Bump a Pending Splice with RBF

Because a splice transaction is a normal on-chain Bitcoin transaction before it confirms, it is subject to the same fee market as everything else on the chain. If you submit a splice with a fee rate that turns out to be too low once mempool conditions shift, the funding transaction can replace itself using Replace-By-Fee rather than getting stuck waiting indefinitely.

Check the current recommended fee rate before you splice anything on mainnet, since rates swing throughout the day. As a live example pulled from mempool.space’s fee estimation API on October 12, 2026, mainnet fees sat at roughly 6 satoshis per vbyte for next-block confirmation, 5 for a 30-minute target, and as low as 1 to 2 satoshis per vbyte for non-urgent transactions. A typical single-input, single-output splice transaction running at 150 to 220 vbytes would cost somewhere between 150 and 1,320 satoshis depending on which target you pick, which at a live BTC price near $82,600 works out to well under a dollar in most cases.

# Re-splice with a higher feerate if the original transaction is stuck
lightning-cli --lightning-dir=~/.lightning-a splice "wallet -> 100000sat+fee@500; 100% -> $CHANNEL_ID"

The @500 suffix sets a feerate of 500 satoshis per kiloweight for this specific splice script, which CLN’s dryrun mode can translate into an equivalent satoshis-per-vbyte figure if you want to sanity check it against current mempool conditions before broadcasting.

Step 11: Batch Multiple Splices Into One Transaction

This is where CLN’s splicing implementation goes further than the simple splice-in and splice-out commands used so far. The splice RPC accepts a small scripting language that can move funds between the wallet and multiple channels, or between channels directly, in a single on-chain transaction. Each line, separated by a newline or semicolon on the command line, is one leg of the splice. An arrow points toward where funds are going.

# Take 10,000 sats out of a channel and send to the wallet
lightning-cli splice "$CHANNEL_ID -> 10000sat"

# Add 10,000 sats from the wallet into a channel
lightning-cli splice "wallet -> 10000sat; 100% -> $CHANNEL_ID"

# Move half the balance of one channel into another channel, in one transaction
lightning-cli splice "$CHANNEL_ID -> 50%; 100% -> 07bfddea"

# Split funds evenly across three channels using the wildcard operator
lightning-cli splice "wallet -> 300000sat; * -> 07bfddea; * -> 09ad6278; * -> efc2a7ff"

Run any splice script with a dryrun flag first to see exactly what it would do without broadcasting anything, which is the safest habit to build before running multi-leg scripts against real mainnet channels:

lightning-cli splice "$CHANNEL_ID -> 50%; 100% -> 07bfddea" dryrun=true

Routing node operators managing a dozen or more channels with the same handful of busy peers get the most value out of this. Instead of running four separate splice-out and splice-in pairs to rebalance capacity across four channels, one scripted splice with four legs does it in a single transaction and pays one set of miner fees instead of four.

Step 12: Verify Channel State After a Splice

Do not treat a splice as finished the moment lightning-cli returns a transaction ID. Confirm three things before you consider the channel’s new state settled: the transaction has actually confirmed on-chain, the channel’s reported capacity matches what you expected, and the channel did not get stuck in a splicing-related state like CHANNELD_AWAITING_SPLICE.

lightning-cli --lightning-dir=~/.lightning-a listpeerchannels $NODE_B_ID | jq '{state: .channels[0].state, total_msat: .channels[0].total_msat, to_us_msat: .channels[0].to_us_msat}'

A healthy post-splice channel reports a state of CHANNELD_NORMAL and a total_msat matching your expected new capacity. If the state still shows a splice-pending value several confirmations after broadcast, something is wrong with how the peers finalized the transaction, and that is worth catching before you route any meaningful payment volume through the channel.

Lightning Implementation Splicing Support in October 2026

ImplementationCurrent VersionSplicing StatusFirst Shipped
Core Lightning (CLN)v26.06.9Experimental, behind –experimental-dual-fundLow-level RPCs in v23.08; splicein/spliceout in v26.04
Eclairv0.14.3Production, final spec versionv0.14.0, May 21, 2024
LDKv0.3.0-beta1Supported since v0.2v0.2, December 2, 2025
LNDv0.21.4-betaNot shipped, groundwork onlyNot yet shipped as of Oct. 2026

The gap between Eclair and LND is the one that matters most for the average node operator. LND remains the dominant client among routing node operators according to implementation comparison data tracked by Spark’s Lightning implementation research, which means a large share of the network still cannot splice at all without switching implementations or waiting for LND to catch up. Until that changes, any splicing-dependent liquidity strategy needs a fallback plan for peers running LND, generally the traditional close-and-reopen workflow splicing was designed to replace.

Core Lightning’s own operational track record is worth weighing before you lean on its experimental splicing code for anything beyond testing. The project has had its share of rough patches, including an incident covered in coverage of Core Lightning’s 14-day lockdown that left a meaningful chunk of bitcoin temporarily inaccessible. None of that is a reason to avoid CLN outright, since the project also ships fixes quickly once a problem is identified, but it is a reason to keep splicing experiments confined to regtest and small signet balances until the feature has a longer production track record behind it.

Common Pitfalls When Splicing Lightning Channels

Splicing introduces new failure modes that do not exist with a simple channel open or close. Watch for these five in particular.

  • Assuming both peers support splicing just because your node does. Feature negotiation happens per channel, and a peer running an older build or a different implementation without splicing will reject the attempt with a generic error rather than a clear splicing-not-supported message.
  • Treating an unconfirmed splice transaction as final. The channel can stay in a transitional state for the duration of the confirmation wait, and routing payments through it during that window can behave inconsistently across implementations.
  • Underpricing the fee on a splice-out. Since the fee for a splice-out comes out of channel funds rather than the wallet, an underpriced transaction can sit stuck in the mempool for hours, tying up the channel’s balance until it either confirms or gets replaced.
  • Running concurrent splices on the same channel. Most implementations only support one in-flight splice per channel at a time. Firing off a second splice command before the first one resolves typically returns an error rather than queuing the operation.
  • Forgetting the 1% channel reserve. Both splice-out and plain channel closes respect a minimum reserve requirement on each side of the channel. A script that tries to splice out 100% of available funds will come up short of the full balance, which surprises people who expect it to behave like a full channel close.

Troubleshooting Guide for Splice Failures

SymptomLikely CauseFix
splicein command not foundCLN was not compiled or started with experimental dual-funding enabledRebuild with –enable-developer and restart with –experimental-dual-fund
Peer rejects splice attempt immediatelyPeer’s implementation or version lacks the splicing feature bitCheck listpeerchannels features output. Confirm peer runs CLN v26.04+, Eclair v0.14.0+, or LDK v0.2+
Splice transaction stuck unconfirmed for hoursFee rate too low for current mempool conditionsRe-splice with a higher feerate using the @ fee operator, or wait for mempool congestion to clear
force_feerate error on spliceoutCalculated fee looks abnormally high relative to amount being spliced outRe-check current mempool.space fee estimates. Only override with force_feerate=true if you have verified the rate yourself
Channel stuck in CHANNELD_AWAITING_SPLICEOne peer disconnected mid-negotiation before exchanging final signaturesReconnect both peers and re-run the same splice command. CLN will attempt to resume the pending negotiation
spliceout amount exceeds available balance errorRequest ignored the 1% channel reserve requirementReduce the requested amount to stay under total balance minus the reserve, or close the channel instead
dryrun output does not match expected feeFeerate specified in sats per kiloweight, not sats per vbyteConvert using the standard 4x weight-to-vbyte ratio, or let dryrun print the vbyte-equivalent rate directly
Cross-splice to another channel fails silentlyDestination channel ID typo or ambiguous partial channel ID matchUse listpeerchannels to copy the exact channel_id, or use enough leading digits to avoid ambiguity

Advanced Tips for Production Splicing

Once the basic splice-in and splice-out flow is working reliably, a few habits separate a safe production setup from one that works fine until it doesn’t. Set a hard minimum fee-rate floor in whatever automation you build, since a script that always takes the cheapest available fee rate will eventually submit a splice right before a fee spike and leave it stuck for a day.

Combine splice legs whenever you are touching more than one channel in the same maintenance window. A four-channel rebalance run as four separate transactions pays miner fees four times. The same rebalance expressed as one scripted splice with four legs, using the wildcard operator shown in Step 11, pays once. On a node managing dozens of channels, that adds up over a year of routine rebalancing.

If your peer runs a lease-capable implementation, consider a splice that both adds your own liquidity and requests the peer add some of theirs in the same transaction, using the lease-request pipe operator in CLN’s splice scripting language. That turns a one-sided liquidity top-up into a negotiated capacity increase on both sides of the channel, at the cost of whatever lease fee the peer charges.

Finally, log every splice attempt with its PSBT and transaction ID before broadcasting, not after. If a splice fails partway through negotiation, having the intermediate PSBT on hand makes it far easier to work out what state the channel is actually in rather than guessing from the next listpeerchannels output.

Complete Working Project: A Splice-Aware Liquidity Script

The script below watches a channel’s outbound liquidity ratio and automatically triggers a splice-in from the node’s on-chain wallet when outbound capacity drops below a configurable threshold. It wraps lightning-cli directly rather than depending on an external RPC library, so it only needs a working CLN installation and Python 3.10 or later to run.

#!/usr/bin/env python3
"""
splice_liquidity_watch.py
Monitors a Lightning channel's outbound liquidity and splices in
funds from the on-chain wallet when the ratio drops too low.
Requires Core Lightning v26.04+ with --experimental-dual-fund enabled.
"""

import json
import subprocess
import sys
import time

LIGHTNING_DIR = "~/.lightning-a"
PEER_ID = "REPLACE_WITH_PEER_NODE_ID"
MIN_OUTBOUND_RATIO = 0.20      # splice in once outbound drops below 20%
SPLICE_IN_AMOUNT_SATS = 500_000
CHECK_INTERVAL_SECONDS = 300
MAX_FEERATE_PER_KW = 2000      # safety ceiling before skipping a splice


def run_cli(*args):
    cmd = ["lightning-cli", f"--lightning-dir={LIGHTNING_DIR}", *args]
    result = subprocess.run(cmd, capture_output=True, text=True, check=True)
    return json.loads(result.stdout)


def get_channel_state(peer_id):
    data = run_cli("listpeerchannels", peer_id)
    channels = data.get("channels", [])
    if not channels:
        raise RuntimeError(f"No channel found for peer {peer_id}")
    return channels[0]


def outbound_ratio(channel):
    total = int(channel["total_msat"].rstrip("msat"))
    to_us = int(channel["to_us_msat"].rstrip("msat"))
    if total == 0:
        return 0.0
    return to_us / total


def estimate_current_feerate_per_kw():
    # In production, replace this with a call to your own fee estimator
    # or a trusted mempool fee API, converted from sat/vbyte to sat/kw.
    feerates = run_cli("feerates", "perkw")
    return feerates["perkw"]["opening"]


def trigger_splice_in(channel_id, amount_sats):
    feerate = estimate_current_feerate_per_kw()
    if feerate > MAX_FEERATE_PER_KW:
        print(f"Feerate {feerate} sat/kw exceeds ceiling, skipping splice")
        return None

    print(f"Splicing in {amount_sats} sats to channel {channel_id} "
          f"at {feerate} sat/kw")
    result = run_cli("splicein", channel_id, str(amount_sats))
    print(f"Splice broadcast: txid={result.get('txid')}")
    return result


def main():
    print("Starting splice-aware liquidity watcher")
    while True:
        try:
            channel = get_channel_state(PEER_ID)
            ratio = outbound_ratio(channel)
            state = channel.get("state")
            print(f"Channel state={state} outbound_ratio={ratio:.2%}")

            if state == "CHANNELD_NORMAL" and ratio < MIN_OUTBOUND_RATIO:
                trigger_splice_in(channel["channel_id"], SPLICE_IN_AMOUNT_SATS)
            elif state != "CHANNELD_NORMAL":
                print(f"Skipping check, channel not in normal state: {state}")

        except subprocess.CalledProcessError as exc:
            print(f"lightning-cli error: {exc.stderr}", file=sys.stderr)
        except Exception as exc:
            print(f"Unexpected error: {exc}", file=sys.stderr)

        time.sleep(CHECK_INTERVAL_SECONDS)


if __name__ == "__main__":
    main()

Run it with python3 splice_liquidity_watch.py after replacing PEER_ID with your actual peer node ID. On a healthy regtest channel it will print a state and ratio line every five minutes, something like Channel state=CHANNELD_NORMAL outbound_ratio=18.00%, followed immediately by a splice broadcast line once the ratio crosses the configured threshold. Before pointing this at a mainnet channel with real funds, run it against the regtest lab from Steps 1 through 3 for at least a full day, and lower CHECK_INTERVAL_SECONDS temporarily so you can watch several splice cycles complete without waiting hours between each one.

Treat the fee ceiling constant as the single most important safety setting in this script. A liquidity watcher that splices in the middle of a fee spike because nobody set a sane ceiling will cost far more in miner fees than the liquidity problem it was trying to solve.

Network Context: Why Splicing Matters Right Now

Lightning Network capacity and node counts have fluctuated through 2026 depending on which graph snapshot and provider you check, which is itself a reason splicing matters. According to mempool.space's lightning statistics endpoint, the public network carried roughly 33,283 channels and 16,405 nodes as of its most recent snapshot, with an average channel capacity of about 11.5 million satoshis and a median routing fee rate of 103 parts per million. Growth and churn tracking from research summarized by CoinLaw's Lightning usage statistics points to a network where individual channels open and close constantly as operators chase better routing positions, and every one of those churn events used to mean a full close-and-reopen cycle and its associated fees.

Splicing does not change how many channels exist. It changes how often operators need to destroy and rebuild one just to adjust its size. Background reading from Speed's research on the future of Lightning settlement frames this as part of a broader shift toward treating Lightning channels as persistent payment infrastructure rather than disposable routing paths, and splicing is one of the clearer technical steps in that direction. For newer node operators still getting oriented, a plain-language primer like Plisio's guide to the Lightning Network or Banxa's explainer on what the Lightning Network is covers the fundamentals splicing builds on top of.

Splicing Versus Closing and Reopening: A Cost Comparison

FactorClose + Reopen ChannelSplice-In / Splice-Out
On-chain transactions requiredTwo (close, then open)One
Routing availability during the processNone, channel is fully closedMostly preserved via quiescence
Channel ID / routing historyLost, new channel ID assignedPreserved in most implementations
Typical confirmation waitTwo separate confirmation waitsOne confirmation wait
Supported across major implementations todayYes, universallyCLN (experimental), Eclair, LDK; not yet on LND

The routing-history column is easy to overlook but matters in practice. A freshly opened channel has to rebuild its reputation in pathfinding algorithms that favor established, reliably-routing channels. A spliced channel skips that cold start entirely, since to the rest of the network it never stopped existing.

Security Considerations Before Splicing Production Funds

Splicing touches the same funding transaction that secures your channel balance against a dishonest counterparty, so the usual Lightning security habits still apply and a few new ones get added on top. Back up your node's channel state after every splice, not just after opening or closing a channel. Most implementations store the data needed to recover funds from a force-close in a static channel backup or an emergency recovery file, and that file changes shape the moment a splice confirms a new funding transaction. A backup taken before the splice points at an output that no longer matches the channel's current state, which can complicate recovery if you ever need to force-close instead of relying on your peer's cooperation.

Watch your on-chain wallet's UTXO set closely if you automate splicing the way Step 12's script does. An automated splice-in script that runs unattended for weeks can quietly drain a wallet down to dust-sized UTXOs if the splice amount and check interval are not sized to the wallet's actual balance. Pair any automation with a minimum wallet balance check so the script refuses to splice once on-chain funds drop below a threshold you are comfortable with, separate from the fee-rate ceiling already built into the example script.

If you are running a node that also doubles as a hot wallet for day-to-day spending, treat splice-out destinations the same way you would treat any other on-chain withdrawal address. A typo in a destination address during a splice-out sends funds to an address you may not control, with no channel-level mechanism to reverse it once the transaction confirms. The same discipline that applies to cold storage planning, discussed in guides on Lightning implementation security patches, applies directly to any address you type into a spliceout command.

Frequently Asked Questions

Does splicing work between different Lightning implementations?
Yes, as long as both sides support the finalized BOLT splicing specification merged in pull request #1160. CLN, Eclair, and LDK can splice with each other today. LND cannot yet splice with anyone, since the feature has not shipped in any LND release as of October 2026.

Is splicing safe to use on mainnet right now?
Eclair's splicing implementation has been in production since May 2024 and is the most tested option. Core Lightning's splicing remains gated behind an experimental flag as of its v26.06.9 release, which is a direct signal from the project that it has not yet cleared their own bar for stable, non-experimental status.

Can I splice a channel while it has pending HTLCs?
Implementations use quiescence to pause new HTLCs briefly during the splice negotiation, but a channel with a large number of in-flight HTLCs at the exact moment you try to splice may need to wait for those to settle first.

What happens if my peer goes offline mid-splice?
The channel typically lands in a transitional state such as CHANNELD_AWAITING_SPLICE until both peers reconnect. Once reconnected, CLN attempts to resume the pending negotiation rather than requiring you to start over, though this depends on how far the negotiation had progressed before the disconnect.

Does a splice-out let me withdraw 100% of a channel's balance?
No. Channel reserve requirements, typically 1% of channel capacity on each side, still apply during a splice-out the same way they apply to a cooperative close. To fully empty your side of a channel you still need to close it.

How much does a splice transaction cost in fees?
It depends entirely on current mainnet fee rates and the transaction's size, generally 150 to 250 vbytes for a simple splice. Check current fee estimates before broadcasting rather than relying on a fixed assumption, since Bitcoin fee rates can move several times within a single day.

Can I batch splices across more than two channels in one transaction?
Yes, using CLN's splice scripting language described in Step 11. The scripting syntax supports an arbitrary number of legs moving funds between the wallet and multiple channels, or directly between channels, settled in a single on-chain transaction.

Will splicing replace channel rebalancing techniques like circular rebalancing?
No, they solve different problems. Techniques covered in guides on Lightning channel rebalancing move liquidity between channels you already have without changing total capacity, which costs only a routing fee. Splicing changes a channel's actual on-chain-backed capacity, which costs a Bitcoin transaction fee. Many operators use both together.