Core Lightning 26.06: "Quantum-Resistant Lightning Channel”

Following on the heels of our last major release, Core Lightning’s 26.06 version focuses heavily on paving the way for the future of payments, refining node operations, and polishing the edge cases of liquidity management.

Whether you are running a routing powerhouse or building next-generation Lightning applications, v26.06 brings improvements to your node's performance, stability, and control.

The Xpay Evolution

If there is a theme to this release, it is the quiet, powerful ascension and future proofing the xpay architecture. 

By default, the legacy pay command will now be handled under the hood by xpay (though you can toggle xpay-handle-pay=false if you need the old behavior). To make this transition seamless, pay now accepts invstring as a parameter name for BOLT11 invoices.

This release introduces a suite of advanced payment commands and protocol enhancements:

• xkeysend: The modern successor to keysend, equipped with cutting-edge routing support.
• sendamount: A brand new JSON-RPC command that lets you specify the exact amount you want to send, rather than the amount to be received—ideal for precise liquidity and fee management.
• Enhanced Privacy: xpay now utilizes shadow CLTV additions to mask the final destination of payments in accordance with BOLT 7, keeping your transactions more secure against network observation.
• Smarter Retries: If xpay receives a channel_update inside an error message, it will dynamically adapt and update for the current payment loop on the fly.
• Note on Deprecations: legacy commands like keysend, pay, paystatus, and getroute are now formally deprecated. We strongly encourage developers to begin moving their applications over to xkeysend, xpay, listpays, and getroutes.

Exiting with Style: Graceful Shutdowns

Reliable operations means being able to turn your node off just as smoothly as you turn it on. This release introduces the graceful JSON-RPC command, giving operators a clean, predictable way to prepare Core Lightning for a shutdown without disrupting active processes.

Complementing this, the systemd lightningd.service script has been updated to handle node shutdowns flawlessly.

On the protocol side, Core Lightning has aligned with the latest BOLT specifications to drastically increase network resilience: with 26.06, the node will wait 72 blocks (up from 12) before closing channels during specific dispute windows, giving peer routing environments a much safer cushion.

Splicing & Wallet Polish: Keeping Every Sat

In our last release v26.04, we gave a "standing splice-ovation" to the arrival of channel splicing. This release irons out the wrinkles to enhance the experience.

We’ve resolved a high-fee edge case that previously caused splicein and spliceout commands to prematurely abort. Additionally, we fixed an issue where channel balances involving partial sats could stall splicein, spliceout, and dev-splice routines. Splicing is now faster, cheaper, and safer than ever.

The internal wallet also received a massive financial efficiency upgrade:

• Change Output Protection: Internal transactions will now correctly create change outputs (>330 sats) for P2TR and P2WPKH addresses.
• Previously, these small change amounts were occasionally absorbed directly into the transaction as miner fees. Now, your node holds onto every single sat it's entitled to.

Better Visibility, Tracing, and BOLT12 Proofs

For enterprise node runners and developers tracking performance at scale, v26.06 introduces a Unix-domain socket sink for OpenTelemetry traces. This allows you to pipeline detailed node performance and lifecycle metrics directly into your existing monitoring stacks (like Prometheus or Grafana) with zero friction.

We have also expanded our experimental tooling to better support the growing ecosystem around BOLT12:

• createproof: A new experimental RPC that generates a cryptographic payment proof for a successful BOLT12 payment.
• decode: Now natively supports payer proofs, making it incredibly easy to verify transactions externally.

Finally, we’ve dialed back message-padding to be off by default. While great in theory for preventing traffic analysis, out-of-spec protocol implementations elsewhere in the wider Lightning ecosystem were struggling to interpret the padded messages. Turning it off guarantees maximum interoperability across all node types.

Bwatch: Our Block Processing Revolution

You might have spotted a quiet entry in our experimental features for a new tool called bwatch. Don't let the experimental tag fool you, this is a foundational architectural shift designed by Sangbida Chaudhuri and Rusty Russell that fundamentally re imagines how Core Lightning interacts with the Bitcoin blockchain.

Historically, lightningd bore the brunt of block processing. Every 30 seconds, it would poll the bcli plugin, pull raw block information from bitcoind, and manually parse the entire block to match relevant script pubkeys, outpoints, and transaction IDs derived from its database. For large nodes, this is heavy work; for leaner nodes, bwatch provides an opportunity to reduce the resource drain of Core Lightning.  

bwatch elegantly solves this by positioning itself as an intelligent middleman between lightningd and bcli:

[ Bitcoin D ] <—> [ BCLI Plugin ] <—> [ Bwatch Plugin ] <—> [ Lightning D ]

Instead of forcing lightningd to continuously monitor the chain, lightningd simply registers its specific "watches" with bwatch. From there, bwatch offloads the entire block-parsing burden:

• Noise-Filtering for Light Nodes: bwatch handles the raw block data and runs ultra-fast O(1) lookups using in-memory hash tables. It only passes updates back to lightningd when a watch is actually matched. 
• Watch Persistence: Unlike old ephemeral watches that had to be reconstructed completely on node restart, bwatch persists watches and block history straight to its own data store.
• Blazing Fast Catch-Ups: On startup, the plugin rehydrates its state and rapidly catches up to the bitcoind tip without waiting for the standard 30-second polling loops, making node recovery smoother than ever.
• Advanced Tracking Capabilities: This framework introduces new specialized watch types, including short channel ID watches and block depth watches, which allow a node to seamlessly track chain depth (like waiting 6 confirmations for a channel opening) asynchronously without needing continuous, manual check-ins.
• Crash-Resistant & Asynchronous: Shifting to an asynchronous model requires industrial-grade reliability. bwatch utilizes a robust command acknowledgment system and a pending operations queue to ensure that no critical notification is ever dropped if a process crashes. Even blockchain reorganizations (reorgs) are cleanly isolated, allowing the system to roll back updates on a precise, per-watch basis via the revert_block_process routine.

By opting for a clean, extensible JSON-RPC plugin architecture, bwatch paves the way for future deployments where a single, centralized block-watching engine can efficiently service multiple independent nodelets simultaneously.

Acknowledging Our Contributors

Core Lightning releases are fueled by an incredible open-source ecosystem. In 42 days, our community merged 236 commits by 19 authors to get v26.06 into production.

A massive shout-out to our core maintainers and heavy-lifters keeping the repository flying: Rusty Russell, Shahana Farooqui, Sangbida Chaudhuri, Christian Decker, Lagrang, Peter Neuroth, Lisa Neigut, Daywalker, and Níckolas Goline.

Thank you to everyone who contributed code, submitted bug reports, tested features, and kept our open-source community moving forward!

Connect with Us

We strongly encourage you to try out Core Lightning v26.06. Share your feedback and stay connected with us through the Core Lightning team on GitHub, Discord, and X.