Core Lightning tagged v26.04rc1 on March 26, 2026, shipping three new commands — splicein, spliceout, and a cross-splice operation — that formalize channel liquidity management as a first-class feature for the roughly 15,000 public Lightning Network nodes that route payments daily. The release marks the clearest sign yet that splice, once a developer experiment requiring raw RPC gymnastics, is now considered production-ready tooling.
Splice has been technically possible on Core Lightning for some time, but the absence of purpose-built commands meant that node operators and Lightning Service Providers had to assemble multi-step RPC sequences to accomplish what are, fundamentally, routine liquidity tasks. The v26.04rc1 release resolves that gap entirely. Splicein adds funds to a live channel without closing it; spliceout removes funds; the cross-splice operation goes further, allowing an operator to name a second channel ID as the destination of a spliceout — effectively moving funds between two distinct channels in a single coordinated on-chain transaction. The practical implication for a routing node operator is significant: liquidity rebalancing that once required closing and reopening channels, burning fees and blocking payment flow during the confirmation window, can now be accomplished with a single command and without interrupting routing.
The release notes also document improvements to payment reliability through parallel pathfinding and multiple bug fixes in the askrene pathfinding engine, a new fronting_nodes option on offer, and a payment-fronting-node configuration option that applies preferred routing peers consistently across both BOLT11 and BOLT12 payment flows. A new payer-note field in the xpay command lets senders attach notes to payments. The listpeerchannels command gains the ability to filter by channel_id. Cross-implementation work is also reflected in the release: Core Lightning pull request 8817, part of the v26.04 cycle, addresses several splice interoperability issues with Eclair discovered during joint testing, including handling of channel_ready messages during splice reestablishment and announcement signature retransmission via new channel_reestablish TLVs. That kind of cross-client friction surfacing and resolution is how a feature graduates from 'technically works in isolation' to 'reliably works across a heterogeneous network.'
The broader protocol stack is in motion simultaneously. Bitcoin Core v31.0rc2 was tagged on March 25, 2026, one day before the CLN release candidate, placing the two most widely deployed implementations in concurrent late-stage testing cycles. The Bitcoin network itself, as measured by Mempool.space at block height 942,563, is running at a hashrate of 1,004.5 EH/s — sustaining record-level proof-of-work security — while fees sit at 1 satoshi per virtual byte across fastest, 30-minute, and 1-hour confirmation tiers. That fee environment is not a coincidence to dismiss lightly: operators managing channel opens, UTXO consolidations, or splice funding transactions are unlikely to see a lower-cost on-chain window in any near-term period of high network activity. On the covenant research front, BIPs #1974 published BIP446 and BIP448 as Draft BIPs this week. BIP446 specifies OP_TEMPLATEHASH, a new tapscript opcode that pushes a hash of the spending transaction onto the stack; BIP448 bundles OP_TEMPLATEHASH with OP_INTERNALKEY and OP_CHECKSIGFROMSTACK under the label 'Taproot-native (Re)bindable Transactions.' The pair would, if activated, enable LN-Symmetry — a channel construction that eliminates the need for per-state penalty transactions — alongside broader reductions in interactivity for second-layer protocols. On the LDK side, pull request 4427 adds RBF fee-bumping support for splice funding transactions that have been negotiated but not yet locked, using a quiescence re-entry mechanism; LDK #4484 raises the maximum accepted channel dust limit to 10,000 satoshis for anchor channels with zero-fee HTLCs, implementing the recommendation from BOLTs #1301.
No direct developer statements were available from Core Lightning maintainers or Bitcoin Core contributors at time of publication — the v26.04rc1 release notes are formatted as technical documentation rather than attributed commentary, and no public statements had been indexed for the March 26–28 window. The zk-X509 paper (arXiv:2603.25190v1), authored by Yeongju Bak and submitted March 26, 2026, had no accompanying public statement indexed at time of brief preparation. The paper itself argues that the approximately 4 billion active X.509 certificates already embedded in global public-key infrastructure — the same certificates that secure HTTPS connections — can serve as the credential base for on-chain identity attestations via zero-knowledge proofs, without requiring centralized KYC attestors, trusted execution environments such as TEEs, or purpose-built DID credential frameworks. The argument is that the trust infrastructure already exists at civilisational scale; the missing piece was a way to make proofs about certificate fields without exposing the underlying identity data.
For builders, the convergence of these developments points in one direction: the Lightning stack is moving from protocol-layer correctness toward operator-layer usability, and the research community is beginning to treat ZK proofs not as an exotic cryptographic novelty but as a practical bridge between legacy institutional infrastructure and sovereign on-chain systems. The signals worth watching in the near term are threefold: first, whether v26.04 reaches a stable release tag without material regressions in the splice interoperability work with Eclair, which will determine whether LSPs can deploy the new commands confidently on mainnet; second, the progression of Bitcoin Core v31.0 to a final release, at which point the v31 feature set becomes the baseline for node operators globally; and third, whether the zk-X509 paper attracts implementation interest from any existing on-chain identity or compliance-tooling projects — the distance between an arXiv submission and a deployable proof system is long, but the X.509 bridging approach is specific enough that the next indicator will be a concrete proof-of-concept repository, not another theoretical paper.