Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week was the Vegas conference, which brought us the announcement of the LDK Server. We also learned about a low-severity Electrum vulnerability, and watched implementation work follow its course.

LDK ServerLDK Server

Spiral engineer Ben Carman unveiled the LDK Server during the Bitcoin 2026 conference in Las Vegas. As the name suggests, it's a deployable server built on top of the Lightning Dev Kit, with minimal configuration required and the ability to serve a wide variety of use cases.

Until now, node operators wanting to use LDK had to get their hands on at least some code in order to integrate the LDK into their own solution. Things like the LDK Node library help a bit in streamlining this operation, but it still requires extra work than just running a daemon.

With the LDK Server, operators can just grab or build the release, configure a few things, and get their LDK node running with a simple command^[1]. The goal is to be able to serve a wide variety of use cases (from end-users on potato servers to enterprise scale deployments), thanks to the underlying LDK modularity. For example, the LDK server can be used:

• either with a full Bitcoin node or an Electrum server ;
• either as an LSP client or to provide LSP services.

Since it's LDK based, it ships with all the latest Lightning niceties: splicing, Bolt12, zero-fee commitments, etc. It aims to offer a clean API and CLI to interface with these features^[2].

This new project is still in an early phase, so APIs are still under development and breaking changes can be expected. If you're willing to give it a try, feedback and contributions are welcome!

Electrum NWC VulnerabilityElectrum NWC Vulnerability

The Electrum team disclosed a low-severity vulnerability in its Nostr Wallet Connect (NWC) internal plugin. It was patched in version 4.7.2, released April 1st, and all previous versions are affected.

The NWC internal plugin runs a server that enables clients to interact with the Lightning wallet, including sending payments^[3]. It is a good practice to give NWC connections a budget, an expiration date, and in some instances limit access to only a sub-wallet. The electrum NWC plugin implements expiration and a 24-hours rolling window budget. If you set this daily budget to 1,000 sats, the plugin will reject payment requests from a connection if it would go over the budget.

The disclosed vulnerability is comprised of 2 separate bugs affecting this budget safeguard:

• a race condition, where a malicious client could craft 2 payment requests and submit them simultaneously, passing the budget check for both whereas only one should have succeeded. For example, on a 1,000 sats untouched daily budget, sending two 1,000 sats payment requests simultaneously could work, because both would pass the check. The attacker could spend 2,000 sats, doubling the expected budget ;
• a rounding bug, where millisatoshis would be truncated (e.g. a 1.999 sat amount would be truncated to 1 sat) when accounting for the sent amount in the budget. On repeat, this could let a client exceed the daily limit by at most a 1.999 factor^[4].

The bugs were reported by maru1009 and patched in version 4.7.2 of Electrum.

X Announcement

Splicing Work In The ImplementationsSplicing Work In The Implementations

With splicing now part of the Lightning specification, developers are pushing fixes and improvements to their respective implementations of splicing. Last week, rust-lightning notably shipped 2 small splicing-related fixes ; while Eclair replaced their experimental version of some splicing messages with their specification-compliant versions.

Rust-lightning (LDK)Rust-lightning (LDK)

Pull request 4577 fixed two timing issues that could lead to unnecessary force closes, either if the splice transaction confirmed while peers were offline^[5] ; or if for some reason a message was received from a peer that referred to the old short channel id of the channel instead of the post-splice one^[6].

EclairEclair

In PR 2887 the Eclair team replaced the legacy, experimental implementation of splicing with the official one. Since backward compatibility is especially important in Eclair's context (with a lot of Phoenix nodes that may take some time to update, and need to be able to splice with Acinq's node regularly), Eclair still maintains the legacy version, and will use this version if peers signal splicing support using the experimental feature bit.

RailsX In ThunderHubRailsX In ThunderHub

Amboss' RailsX solution for self-custodial Taproot Assets stablecoin trading on Lightning was added to ThunderHub. It's great to see RailsX out in the real world in a product node operators are used to, and I'm curious to see if it catches on. Of course, it's also worth noting that ThunderHub maintainer Anthony Potdevin is also Amboss' co-founder and CTO.

Quick StrikesQuick Strikes

• Shadowbip released ln-health, a nice TUI tool to quickly check the health of an LND or Core Lightning node. A variety of parameters are summarized into a global note, and the tool also makes it easy to share the results on Nostr ;
• after demonstrating Eltoo on signet with APO + CTV, Aaron Zhang ran the same experiment with CSFS + CTV ;
• nominations are open for the 2026 Bitcoin Research Prize by Chaincode. If you (co)authored a peer-reviewed paper, published after January 1st 2022 that was relevant to Bitcoin or Lightning, you can anonymously submit it for this year's prize. Also, you can check out the Bitcoin Research Day website to see the leaderboard of the last years.

That's it for last week! As always, I want to thank you for reading this far. If you want to support this newsletter, you can share it with your colleagues and friends, or even on the open internet (I know, it's scary out there!). By the way, I'll be in Viareggio next week for the Tuscany Lightning Summit, so feel free to hit me up if you're there as well. Until next week!

1. See the Getting Started page for more details. ↩

2. See Ben's presentation slides for more details on supported features, enterprise-readiness, etc. ↩

3. Sending payment capability can be disabled by setting the max-allowed daily budget to 0, meaning such a NWC connection can only be used by the client to query information about the wallet (e.g. balance) and fetch invoices. ↩

4. Example: on 1,000 sats budget, each 1.999 sat sent payment is accounted for only 1.0 sat. This means the NWC server would allow one thousand of those payments to take place a day, effectively raising the budget from the expected 1,000 sats to 1,999 sats. ↩

5. Commit 21fed17 (that's a funny hash!). ↩

6. Commit 80528b1. ↩