Core Lightning v26.04rc1 marks the point at which channel splicing transitions from a research-grade capability into an operator-grade workflow. The Blockstream-led Core Lightning team tagged v26.04rc1 on March 26, 2026, introducing the 'splicein' and 'spliceout' commands — the first high-level, user-facing API for resizing live Lightning channels without closing and reopening them — alongside a cluster of privacy, routing, and reliability improvements that collectively advance CLN's position as the most extensible Lightning implementation in active development.
The Lightning Network's competitive landscape is defined by three principal implementations: LND (Lightning Labs), Core Lightning (Blockstream/community), and Eclair (ACINQ). Each targets overlapping but distinct operator segments — LND commands the largest installed base among consumer wallets and LSPs, Eclair powers the Phoenix and Breez infrastructure stacks, and CLN dominates among technically sophisticated node operators who value its plugin architecture and standards-compliance. Channel splicing — the ability to add or remove liquidity from an existing channel via an on-chain transaction without a channel close — is the most consequential unsolved UX problem in Lightning capital management. Operators today must choose between locking capital in a channel indefinitely or paying the full cost of a close-and-reopen cycle. Neither option is efficient. The total addressable improvement is difficult to quantify precisely, but routing nodes and LSPs that manage dozens or hundreds of channels absorb meaningful on-chain fee drag and opportunity cost from this constraint every week.
The v26.04rc1 release, tagged at the official ElementsProject/lightning GitHub repository, introduces two new top-level commands: 'splicein', which allows operators to splice funds into an existing channel, and 'spliceout', which removes funds from a channel back to an on-chain address. A third capability — cross-channel splicing — allows a 'spliceout' operation to target a second channel ID as its destination, enabling operators to rebalance capital between two channels entirely on-chain without an external withdrawal. The release also adds a 'payer-note' field in 'xpay', a 'channel_id' filter in 'listpeerchannels', a 'fronting_nodes' option in the 'offer' command, a new 'payment-fronting-node' config for BOLT11 and BOLT12 routing, peer message padding to uniform length, 'clnrest-register-path' for dynamic plugin HTTP endpoints, and a synchronous rewrite of the 'bcli' plugin. Parallel pathfinding improvements and multiple bug fixes in the 'askrene' routing module round out the reliability changes. (Technical readers: the 'bcli' synchronisation removes the async queue complexity that had been a source of intermittent Bitcoin backend interaction failures in prior releases.)
This release is happening now because three distinct forces converged. First, the low-level 'splice_init' infrastructure shipped in CLN v23.08 — roughly 31 months ago — giving the team a stable foundation to build the high-level UX layer without rushing the protocol design. Second, Bitcoin mempool fees are at 1 sat/vB across all confirmation tiers as of block height 942,660 (Mempool.space), the lowest practical fee floor, which means splicing transactions can be broadcast today at negligible on-chain cost — an operational reality that accelerates operator incentive to test and adopt the feature. Third, the broader Lightning ecosystem is under sustained pressure from LSPs and mobile wallet providers to deliver capital efficiency tools that reduce the friction of channel lifecycle management; the commercial demand for splicing has never been higher. The precedent is the dual-funding protocol, also pioneered by CLN (led by Lisa Neigut, @niftynei), which took a similar arc from low-level experimental RPC to production API before being adopted by competing implementations.
CLN's high-level splicing API creates direct competitive pressure on LND and Eclair. Node operators running CLN gain immediate access to a workflow — resize a channel, move capital between channels, all without a close cycle — that LND and Eclair operators cannot replicate today with equivalent simplicity. This shifts operator convenience significantly toward CLN for any routing node or LSP whose primary pain point is channel liquidity management. The second-order effect is on LSP economics: services like Voltage, Amboss, and independent routing operators that manage large channel portfolios will have a quantifiable on-chain fee saving available to them the moment v26.04 reaches general release. LND's team has been active on splicing research, but has not yet shipped equivalent high-level commands; if v26.04 reaches final release in the typical 2–4 week window following rc1, CLN will hold this UX advantage through at least mid-May 2026. The peer message padding feature — which pads all peer messages to a uniform length — is a privacy improvement that may or may not be replicated by LND quickly; privacy-sensitive operators running CLN gain a traffic analysis mitigation that is not available on other implementations today.
Our read: v26.04rc1 is a structural inflection for CLN's competitive positioning, not an incremental release. The testable hypothesis is this — if 'splicein' and 'spliceout' survive the RC period without blocking bugs and ship in final form by late April 2026, CLN will record a measurable increase in new node deployments and channel opens among routing-node operators over the following two quarters, as measured by public network graphs (1ML, Amboss). The confirmation signal is adoption velocity among operators with more than 20 channels, who have the most to gain from non-disruptive channel resizing. The disconfirmation signal would be a blocking splice interoperability bug that prevents CLN-to-LND splice transactions from settling cleanly — a scenario that would expose protocol-level gaps and delay practical adoption regardless of the UX quality of the commands themselves. The peer message padding feature is a secondary but important hypothesis: if LND does not ship an equivalent within two release cycles, privacy-sensitive operators — particularly those running nodes in high-surveillance jurisdictions — will have a concrete, feature-driven reason to migrate.
Decision-makers should monitor four specific forward indicators. First, the CLN GitHub issue tracker and CLN Discord for blocking bugs filed against 'splicein', 'spliceout', or the cross-splice workflow during the rc1 testing window — resolution or escalation will be visible within 7–14 days and determines whether the final v26.04 release slips beyond the April 2026 target. Second, LND's GitHub release roadmap and open pull requests tagged 'splicing' — any merge or milestone update in the next 60 days would signal that CLN's high-level API has accelerated LND's own timeline, which would compress CLN's window of UX differentiation. Third, on-chain fee environment via Mempool.space: if fees rise above approximately 10 sat/vB, the economic incentive for operators to test splicing transactions during the RC period diminishes materially, potentially suppressing rc1 adoption data. Fourth, wallet and LSP integration announcements referencing the 'payment-fronting-node' config or BOLT12 fronting support — any public announcement from a named LSP integrating this feature within 90 days would confirm that v26.04's routing ergonomics are being adopted at the infrastructure layer, not just the individual node level.