Core Lightning v26.04rc1 is the release where self-custodied Lightning node operation becomes materially less operationally burdensome, and the gap between CLN and competing implementations widens on two dimensions simultaneously: channel liquidity management and key recovery. Blockstream's ElementsProject team tagged the release candidate on March 26, 2026, shipping purpose-built 'splicein' and 'spliceout' commands alongside BIP-39 12-word seed phrase support for new nodes — a combination that addresses both the operational complexity and the custody-UX deficit that have historically constrained CLN's reach beyond technically sophisticated operators.
The Lightning Network protocol, now processing payments across a channel graph of tens of thousands of nodes, has long faced a structural tension between on-chain capital efficiency and operational simplicity. Splicing — resizing a channel's capacity without closing and reopening it on-chain — has been in experimental stages across CLN releases for over a year, but prior versions exposed it only through lower-level RPC calls requiring manual parameter construction. Separately, CLN nodes have historically generated a 32-byte hex seed as their root secret: cryptographically sound, but non-mnemonic, making backup and recovery cumbersome relative to any BIP-39-compatible on-chain wallet. The three dominant open-source Lightning implementations — CLN (Blockstream/ElementsProject), LND (Lightning Labs), and Eclair (ACINQ, the team behind Phoenix) — compete on exactly this axis of operator experience, and v26.04rc1 moves CLN's position on both vectors in a single release.
The granular specifics of v26.04rc1 are worth unpacking in full. On splicing: the new 'splicein' command allows operators to add funds to an existing channel; 'spliceout' removes them. More consequentially, 'spliceout' accepts a second channel ID as a destination parameter, enabling a cross-splice that routes liquidity directly from one channel into another without an intermediate on-chain settlement step — a capability no other major Lightning implementation currently exposes in a stable release command. On key management: new nodes will be created with a BIP-39 12-word phrase as their root secret, with BIP-39 base functionality integrated into 'lightning-hsmtool' to support 'hsm_secret' files; existing nodes retain their current format with full backward compatibility. The release also ships 'lightningd-downgrade', a database rollback tool that reverts from v25.12 to v25.09, and resolves the long-standing 'missing_utxo' bug. Payment reliability improvements include parallel pathfinding enhancements in the 'askrene' routing engine, an HTLC cap of six per unknown channel in xpay (matching Phoenix's limit), experimental LSPS2-service support, and 'fronting_nodes' options on the 'offer' command for improved BOLT12 routing. All figures and feature descriptions are sourced directly from the v26.04rc1 release notes on GitHub (ElementsProject/lightning, 2026-03-26).
Three structural forces converge to explain why this particular feature cluster arrives now. First, the on-chain fee environment has collapsed: Mempool.space records fees at 1 sat/vB across fastest, 30-minute, and one-hour confirmation brackets as of the research date, at block height 942,815 — an unusually cheap window for on-chain splice transactions and the most favorable testing environment for mainnet splice adoption in recent memory. Second, the LSPS (Lightning Service Provider Specification) standardization effort has reached a maturity level where LSPS2 — the specification governing just-in-time channel opening and liquidity provisioning — is implementable by node software rather than only by custodial LSPs; CLN's experimental LSPS2-service support is a direct response to that standardization milestone. Third, the competitive pressure from mobile Lightning wallets — Phoenix (ACINQ) and Breez in particular — which have offered splice-adjacent liquidity management and mnemonic recovery for their users for some time, has raised operator expectations for what a self-custodied node should be able to do without manual intervention.
The competitive implications of v26.04rc1 run in two directions. For LND and Eclair, the release raises the specification bar: both implementations will face pressure from operators and wallet developers to match the 'splicein'/'spliceout' API design, since cross-implementation splice interoperability is the next major protocol hurdle. CLN's first-mover position on a clean splice UX gives Blockstream a window to shape the emerging API convention before competitors ship their own stable commands. The LSPS2 experimental support is the more subtle competitive move: it positions CLN to interoperate with LSP-compliant wallets — Phoenix, Breez — without a custodial trust assumption, which shifts the value chain dynamic from 'CLN as an infrastructure node for developers' toward 'CLN as a routing and liquidity node that wallet users can interact with directly.' The BIP-39 addition is less a competitive differentiator against LND (which has supported mnemonic seeds for longer) and more a closure of a known adoption barrier for operators migrating from on-chain self-custody into Lightning.
Our read: the strategic significance of v26.04rc1 is not any single feature but the deliberate packaging of splice UX, BIP-39 recovery, and a safety rollback tool in a single release candidate. This is an operator confidence play. Blockstream is signaling that splice is no longer an experimental curiosity — it is a production-track feature with the safety infrastructure (downgrade tooling, database rollback, 'missing_utxo' resolution) that risk-conscious node operators require before touching mainnet channels. The testable hypothesis: if the final v26.04 release ships in mid-to-late April 2026 without material regressions in the RC cycle, CLN's operator base will begin performing mainnet splice transactions within 60 days of the stable release, and wallet teams building on LSPS2 will announce CLN compatibility within the same window. What would disconfirm this: a regression in the 'askrene' pathfinding changes that degrades payment reliability, or a failure to ship a BIP-39 migration path for existing node operators in the final release or an immediate point release, which would limit the recovery-UX improvement to net-new deployments only.
Decision-makers tracking this release should monitor four specific indicators. First, the v26.04 stable tag: CLN's standard release checklist reserves approximately one week post-RC for point release assessment; the stable release is expected mid-to-late April 2026, and any delay beyond that window would suggest non-trivial regressions in the RC cycle. Second, cross-implementation splice API response: watch for LND and Eclair maintainers publishing their own stable splice command designs — convergence on a shared API convention accelerates ecosystem tooling; divergence fragments it. Third, LSPS2 wallet announcements: whether Phoenix or Breez publicly confirm CLN LSPS2 interoperability in the weeks following stable release is the clearest signal that the experimental support has crossed into production viability. Fourth, BIP-39 migration tooling: whether Blockstream ships a migration path for existing node operators — not just new nodes — in v26.04 final or a subsequent point release determines the actual scope of the recovery-UX improvement; if it remains new-node-only, the operator sovereignty benefit is deferred for the installed base.