LDK (Lightning Dev Kit)
Modular Rust library for Lightning. Used by Cash App, Casa, ldk-node, more. Mutiny Wallet was a prominent early user; the shutdown was announced 2024-08-05 and the hosted wallet closed 2024-12-31. Its repos took their last commits in September 2024 and are archived today, so treat Mutiny references below as history, not as a live deployment.
See full overview at ../../lightning/ldk/SKILL.md.
Crates
lightning— core protocol logic.lightning-net-tokio— async TCP transport.lightning-persister— file persistence.lightning-background-processor— task driver.lightning-block-sync— chain sync via bitcoind RPC.lightning-transaction-sync— chain sync via Esplora / Electrum.lightning-rapid-gossip-sync— fast initial gossip.lightning-invoice— BOLT11 invoice handling.ldk-node— opinionated bundled crate.lightning-liquidity— LSP client/server.
Release lines (as of September 2026)
lightningand the sibling core crates — 0.2.6 (2026-09-09). LDK 0.1 (January 2025) was the API-stabilisation milestone; since then the project ships features in minor releases and backports fixes as patch releases on older minor lines.lightning-invoice— 0.34.1 (June 2026).ldk-node— 0.7.0 (2025-12-03), which depends on thelightning0.2 line.maincarries an unreleased 0.8.0.- Next major:
lightning0.3.0-rc1 andlightning-invoice0.35.0-rc1, both published 2026-08-31. No stable 0.3 yet.
ldk-node 0.7.0 added experimental channel splicing, async payments (serving and paying static invoices), a Bitcoin Core REST chain source, and persisted liquidity-service state.
ldk-node quickstart
[dependencies]
ldk-node = "0.7"
use ldk_node::Builder;
use ldk_node::bitcoin::Network;
use ldk_node::lightning_invoice::{Bolt11InvoiceDescription, Description};
let mut builder = Builder::new();
builder.set_network(Network::Bitcoin);
builder.set_chain_source_esplora(
"https://mempool.space/api".to_string(), None);
builder.set_storage_dir_path("/path/to/data".to_string());
let node = builder.build()?;
node.start()?;
let description = Bolt11InvoiceDescription::Direct(
Description::new("Test".to_string())?);
let invoice = node.bolt11_payment().receive(
100_000, // 100k msat
&description, 3600,
)?;
Builder setters take &mut self, so build the builder in a let mut binding rather than chaining off a temporary. Network is
re-exported as ldk_node::bitcoin::Network, not ldk_node::Network.
Bindings (as of September 2026)
Two separate binding families exist and are not interchangeable:
ldk-node 0.7.0 ships UniFFI bindings for Swift, Kotlin and Python
(plus community Flutter bindings), while an older family is generated
directly over the raw lightning crate on top of ldk-c-bindings.
Each entry below says which family it belongs to.
- ldk-swift — iOS/macOS, generated over raw
lightning, not over ldk-node; the SwiftPM product is namedLightningDevKit. Not archived, but no release or commit since 0.0.125 (2025-02-27), so it is still on the pre-0.10.0.xline and does not tracklightning0.2. - ldk-garbagecollected — Java, C# and TypeScript over raw
lightning. Java ships asorg.lightningdevkit:ldk-java0.2.5.0 on Maven Central and TypeScript/WASM as the npmlightningdevkitpackage 0.2.5-0, both published 2026-09-01. There is no separate Kotlin/Android binding over rawlightning— Android consumers use the Java bindings. - ldk-node-jvm / ldk-node-android — ldk-node's UniFFI Kotlin bindings, both 0.7.0 on Maven Central (2025-12-03).
- ldk-node-flutter — Flutter over ldk-node, maintained by LtbLightning.
lightningdevkit/ldk-nodejs — an older Node.js binding — is archived
and took its last commit in May 2022. The maintained JS/WASM path is
the lightningdevkit npm package above, which wraps raw lightning;
there is still no ldk-node WASM/JS binding.
Use cases
- Mobile Lightning wallets.
- Browser-based LN — Mutiny compiled
lightningto WASM before shutting down in 2024; the pattern is still viable, but there is no maintained ldk-node WASM/JS binding to build on. - Custom backend services with Lightning embedded.
Compared
See ../../lightning/ldk/SKILL.md for LND/CLN comparison and full feature matrix.
Version floor and security history (as of September 2026)
- 0.2.6 (2026-09-09) is the floor on the 0.2 line. It fixes a
denial-of-service where a bogus HTLC that is immediately rejected,
after a second HTLC with the same
payment_hashwas already forwarded, could leave theChannelManagerunreadable on deserialization; and a fee-inflation bug letting a malicious splice counterparty make us over-allocate fee into their output when we contribute to a splice. - 0.2.5 and 0.1.12 (both 2026-08-05) fixed an on-chain
funds-theft vulnerability for forwarding nodes that accept channels
from untrusted peers —
ChannelMonitorconfused two HTLCs with equalpayment_hashand amount and resolved them incorrectly — plus several remote-panic DoS vectors (oversized protocol messages, invalid onion-message reply paths, reorg-time claim batching, and the 50-unfunded-peer limit not being enforced). - 0.2.3 (2026-06-18) is superseded by the 0.2.6 floor but worth
knowing about: it fixed anchor-reserve underestimates that could
leave a node unable to properly force-close,
possiblyrandomnot generating random data unless explicitly configured (leaving LDK open to HashDoS), and several remote-triggerable panics. - The 0.1 line received no backport of the 0.2.6 fixes, so 0.1.12 is not a current floor. Move to 0.2.6.
- ldk-node 0.7.0's manifest requires
lightning0.2.0, which is a caret requirement — a fresh resolve picks up 0.2.6, but an existingCargo.lockneedscargo update -p lightningto actually land on it. Check the lockfile, not the manifest.
Migrating to 0.3 (release candidate as of September 2026)
lightning 0.3.0-rc1 changes defaults and invalidates some persisted
state. Plan for:
ChannelHandshakeConfig::negotiate_anchors_zero_fee_htlc_txnow defaults totrue.UserConfig::manually_accept_inbound_channelsis removed — it is always on, so inbound channels must be accepted explicitly from event handling.ChannelHandshakeLimits::max_funding_satoshiswent with it.- Payment metadata is now committed to in the payment secret, so BOLT11 invoices already issued with payment metadata are invalidated on upgrade (and newly issued ones on downgrade). This bites anyone holding long-lived invoices.
- Blinded-path receives are authenticated with a
ReceiveAuthKey; 0.3+ will not accept payments over blinded paths created by earlier versions. Existing BOLT12 offers stay valid; issued-but-unclaimed BOLT12 refunds do not. - Splices can be RBF'd and can add and remove funds in the same splice. A splice negotiated on an earlier version cannot be RBF'd, and downgrade after an RBF is unsupported.
- MSRV rises to rustc 1.75.
During the 0.3 cycle primary rust-lightning development moved to
git.rust-bitcoin.org; GitHub remains a synchronised mirror with
issues forwarded.
Common pitfalls
Persisttrait misimplementation → state corruption.- Async signer race conditions.
- Version migrations require careful state migration.
- Pinning a major without tracking its patch line — LDK backports
security fixes as patch releases, so
0.2alone is not a floor.