Core Lightning v26.04rc1 Splicing RPCs Move to Center

Core Lightning v26.04rc1 splicing RPCs turn splicing from a power-user workflow into an operational API surface. That matters because service builders, liquidity managers, and agent-run payment nodes can now call splicein and spliceout directly instead of stitching together experimental primitives by hand, while still treating the release as a testable pre-release rather than a production baseline.

Core Lightning v26.04rc1 ships more than a routine release candidate

According to the GitHub release artifact, Core Lightning v26.04rc1 adds first-class splicein and spliceout commands, supports cross-splicing by sending the output of a splice to another channel, adds payer-note to xpay, lets listpeerchannels filter by channel_id, improves payment reliability through parallel pathfinding and askrene fixes, and adds protocol and privacy changes such as uniform peer-message padding. The same notes say the release candidate packs 421 commits over 110 days from 23 authors, which is a high level of engineering throughput for a pre-release rather than a small patch train. The repository page shows about 3,000 stars and 980 forks under the ElementsProject organization.

Core Lightning v26.04rc1 release notes

ElementsProject/lightning repository

Bitcoin Optech’s March 27 newsletter frames the new RPCs as a way to add funds from the internal wallet into a channel or remove funds from a channel to the internal wallet, a Bitcoin address, or another channel, without forcing operators to manually construct transactions through the older experimental dev-splice path. That changes the release from “splicing exists” to “splicing is callable.” For node operators building automated treasury or routing workflows, that distinction matters more than almost any single UX tweak in the release notes.

Bitcoin Optech newsletter #398

Core Lightning v26.04rc1 splicing RPCs shift liquidity management into software

Splicing has been one of Lightning’s most useful but most awkward capabilities because it sits at the boundary between channel state and onchain funding. Bitcoin Optech’s 2023 coverage of CLN’s first experimental implementation explained the appeal clearly: users could splice funds in or out without closing the channel, and the channel could keep sending, receiving, or forwarding with the remaining balance while the splice transaction confirmed. The Optech topic index also shows how much work went into interoperability with Eclair during 2025. That property is what makes splicing useful for real operators. It reduces the operational drag of close-and-reopen cycles and lets liquidity adjustment become an ordinary node task instead of a maintenance event.

Bitcoin Optech on CLN’s first experimental splicing support

Bitcoin Optech splicing topic index

The new RPC surface pushes that idea into service architecture. Bitcoin Optech says the underlying CLN work solved a circular fee-estimation problem for cross-channel and multi-channel splices, where adding wallet inputs changes transaction weight and therefore the fee requirement, which can in turn require more inputs. In practice, that means builders are getting more than convenience wrappers. They are getting an API boundary around coordination logic that is easy to get wrong if every service has to script it independently. This is why the release matters for routing services, liquidity marketplaces, and agent-driven payment systems: software can start treating channel resizing as a routine operation with explicit RPC entry points.

Bitcoin Optech on the splicing engine changes behind the new RPCs

The developer surface goes beyond splicing

The release candidate also changes how applications can extend a CLN node at runtime. The release notes say clnrest-register-path allows plugins to register custom HTTP endpoints without restarting the node, and the API reference says the command was added in v26.04 as a low-level mechanism for binding a REST path to an RPC method with optional rune validation. The plugin-development docs place dynamic REST paths alongside JSON-RPC passthrough, hooks, and event subscriptions as part of CLN’s plugin model. For operators running CLN as part of a larger service, that is a real interface shift.

clnrest-register-path reference

Core Lightning plugin development docs

Core Lightning developer coverage→ /news/core-lightning-developer-updates

There are two direct consequences for builders. First, custom service logic can stay closer to the node rather than moving outward into a separate API gateway that has to mirror CLN semantics. Second, access control can remain tied to runes and RPC methods instead of becoming an application-side patchwork. The same release also pads peer messages to a uniform length to reduce traffic analysis, makes the bcli plugin synchronous to simplify Bitcoin backend interactions, and makes Fedora builds reproducible. Those are not headline features, but they tighten the node as a platform for long-running services, especially when operators care about debuggability, deterministic builds, and reducing information leaked through network behavior.

Core Lightning v26.04rc1 release notes

This is where Core Lightning now sits relative to other Lightning stacks

CLN did not invent splicing in March 2026. Bitcoin Optech’s 2025 year-in-review says Core Lightning 25.05 introduced experimental splicing support compatible with Eclair, and the topic index records work toward interoperability with Eclair during 2025. Eclair’s own v0.13.0 release from October 2025 said its splicing implementation had been updated based on spec changes, but also said the splicing specification was still pending and could not yet be used across implementations in the general case. That context matters because CLN v26.04rc1 is a milestone in operational packaging, not the final word on network-wide splicing maturity.

Bitcoin Optech 2025 year-in-review

Eclair v0.13.0 release notes

he comparison also sharpens the risk model. In the same March 27 Bitcoin Optech newsletter that covered CLN’s new RPCs, LDK got a fix for a potential funds-loss scenario during channel funding and splicing when a node could release signatures before durably persisting the relevant monitor update. That is a reminder that “splicing works” and “splicing is safe under crash, fee, and state-transition edge cases” are different claims. CLN’s new commands make automation easier, but builders should still treat splicing as a part of the Lightning state machine where implementation details, interoperability edges, and failure handling deserve review before rolling the feature into unattended production policy.

Bitcoin Optech newsletter #398

What builders can do now, and what still belongs in the RC testing window

Builders can already map the release into concrete workflows. A service node that needs to rebalance local liquidity can now call splicein to add wallet funds to an existing channel, call spliceout to recover idle capital to the internal wallet or a Bitcoin address, or use cross-splicing to move capacity between channels without treating the operation as a close-and-reopen event. A plugin-driven application can also expose a purpose-built REST path at runtime that wraps these or other RPCs with rune-based checks. On the payments side, operators also get better routing from parallel pathfinding and easier channel inspection from filtered listpeerchannels.

Web3 Builder coverage→ /categories/web3-builder

Core Lightning v26.04rc1 release notes

clnrest-register-path reference

The limits are just as clear. This is Release Candidate 1, which means active testing is the point, and CLN’s own release page marks it as a pre-release. Splicing is still tied to counterparties, channel states, and fee environments that can expose edge conditions, and the broader standards picture is still moving across implementations. Builders should test automation around rollback, fee spikes, peer compatibility, channel accounting, and crash recovery before assuming that a new RPC surface alone makes liquidity management safe to hand over to agents. The right reading of v26.04rc1 is that CLN is making liquidity management programmable in a cleaner way. The wrong reading is that one RC erases the operational complexity Lightning has accumulated around channel state.

Bitcoin infrastructure coverage→ /categories/crypto-newswire

ElementsProject/lightning releases

The next signal to watch is not the announcement itself but the stable v26.04 release and the first wave of operator feedback on splicing automation under real fee and peer conditions. If those tests hold, CLN will have moved a hard Lightning maintenance task into normal software control rather than one-off operator intervention.

• GitHub — ElementsProject/lightning v26.04rc1 release — https://github.com/ElementsProject/lightning/releases/tag/v26.04rc1
• GitHub — ElementsProject/lightning repository — https://github.com/elementsproject/lightning