LDK (Lightning Dev Kit)
LDK is a library, not a daemon. Provides Rust crates with C/Swift/ Kotlin/JS bindings. See "Use cases" below for who ships it.
LDK is developed under the lightningdevkit GitHub org — it is not
a Lightning Labs project (Lightning Labs ships LND, Loop, Pool and
Taproot Assets). Dual-licensed Apache-2.0 / MIT.
Versions as of September 2026: the core lightning crate is 0.2.6
(2026-09-09), with 0.3.0-rc1 (2026-08-31) in release-candidate;
ldk-node is 0.7.0 (2025-12-03). The long 0.0.x line ended at
0.0.125 (2024-10-14) and was succeeded by 0.1.0 (2025-01-16), so any
0.0.x version floor you see quoted predates the current API.
Crates (selected)
lightning— core protocol logic.lightning-net-tokio— async TCP transport.lightning-persister— file-based persistence.lightning-background-processor— background task driver.lightning-block-sync— chain sync.lightning-transaction-sync— alternative tx-only sync.lightning-rapid-gossip-sync— fast gossip via signed snapshot.lightning-invoice— BOLT11 invoice handling.lightning-dns-resolver— bLIP-32 onion-message DNSSEC resolution, built on thednssec-provercrate. Versioned on its own track, at 0.3.1 (2026-06-19) while the core crate is on the 0.2 line.lightning-payer-proof— BOLT 12 payer-proof verification. In the workspace onmainfor the 0.3 line and not yet released: crates.io holds only a 0.0.1 name placeholder (2026-08-20, described as a "Dummy package for name hold") as of September 2026.ldk-node— opinionated bundling for quick-start.lightning-liquidity— LSP client/server primitives.bdkintegration crates.
Core primitives
// Persistence trait
trait Persist<ChannelSigner> { ... }
// Channel manager — owns all channels
let chan_mgr = ChannelManager::new(...);
// Chain monitoring — watches outputs, force-close events
let chain_mon = ChainMonitor::new(...);
// Router — pathfinding
let router = DefaultRouter::new(...);
// Background processor — drives async tasks
BackgroundProcessor::start(...);
User code provides:
- KeysManager — produces/derives keys.
- NetworkGraph — channel graph storage.
- EventHandler — react to events (payment received, channel opened).
- Persister — save state to disk / DB.
- FeeEstimator — fee rate source.
- BroadcasterInterface — broadcast txs.
ldk-node (quick-start)
// ldk-node 0.7.0 (2025-12-03): setters take &mut self, so build the
// Builder in place rather than chaining off Builder::new().
use ldk_node::bitcoin::Network;
use ldk_node::lightning_invoice::{Bolt11InvoiceDescription, Description};
use ldk_node::Builder;
let mut builder = Builder::new();
builder.set_network(Network::Bitcoin);
builder.set_chain_source_esplora("https://blockstream.info/api".to_string(), None);
builder.set_storage_dir_path("/path/to/data".to_string());
let node = builder.build().unwrap();
node.start().unwrap();
// Use the node
let address = node.onchain_payment().new_address().unwrap();
let desc = Bolt11InvoiceDescription::Direct(
Description::new("desc".to_string()).unwrap(),
);
let invoice = node.bolt11_payment().receive(amount_msat, &desc, 3600).unwrap();
node.bolt11_payment().send(&invoice, None).unwrap();
ldk-node exposes a single API surface across Rust + Swift/Kotlin/JS
bindings.
Async signer
For hardware wallets / remote signers:
trait NodeSigner { fn ecdh(&self, ...) -> Result<...>; ... }
trait ChannelSigner { fn sign_counterparty_commitment(&self, ...) -> ...; ... }
trait SignerProvider { fn derive_channel_signer(&self, ...) -> ChannelSigner; ... }
LDK supports async signing via EventHandler::handle_event returning
deferred sigs. Useful for hardware-wallet-backed Lightning.
Persistence model
LDK doesn't dictate storage. Common backends:
- File:
lightning-persisterwrites channel state to disk. - Database: SQLite, PostgreSQL — implement
Persisttrait. - Cloud: persist channel state encrypted to cloud storage (Mutiny did this; see "Use cases").
- Trustless replication: VSS (Versioned Storage Service) — the LDK
project's own encrypted cloud storage service
(
lightningdevkit/vss-server, Apache-2.0), not a Lightning Labs product.ldk-node0.7.0 can persist channel state to a VSS server.
Chain sync options
- bitcoind RPC —
lightning-block-syncpolls / ZMQs. - Esplora API —
lightning-transaction-syncvia Esplora REST. - Electrum — same crate, via Electrum protocol.
- Neutrino (BIP157/158) — light-client; for mobile.
Mobile uses Neutrino: lightning-block-sync downloads filters, scans locally for UTXO matches, downloads only relevant blocks.
Bindings
LDK provides:
- Rust native crates.
- C via
lightning-c-bindings. - Swift / iOS via
LDKSwiftandLDKNode. - Kotlin / Android via
LDKKotlinandldk-node-kotlin. - JS / WASM via
ldk-node-js(experimental).
ldk-node specifically targets Swift/Kotlin/JS so mobile devs get a single API.
Use cases
Featured on lightningdevkit.org's homepage as of September 2026:
- Alby Hub — self-custodial LN hub.
- Cash App — backend LN.
- Lexe — hosted self-custodial LDK nodes.
- Lightspark — LN infrastructure.
That strip is a highlight reel, not the full user list: the site's case-studies page enumerates 26 projects as of September 2026, among them Bitkit, Fedimint, LNDK, Megalith, Sensei, Stable Channels, TEOS, VLS, Voltage, Zeus and zinqq.
Not on that page (September 2026):
- Mutiny Wallet — browser-based LN via WASM + LDK. Historical: the
MutinyWallet/mutiny-webrepo is archived, last commit September 2024 (checked September 2026).
Not LDK, despite frequent confusion:
- Phoenix (ACINQ) — built on ACINQ's
lightning-kmp, not LDK. - Greenlight (Blockstream) — CLN-based.
- Casa — no LDK link found, and Casa is absent from the case-studies
page. Casa's only Lightning product was the Casa Node / Sats App,
which ran LND (
Casa/Casa-Node-API: "an API into Bitcoind and LND"; repo archived, last push July 2020) and was sunset 2021-06-30. casa.io advertises no Lightning product as of September 2026.
Memory footprint
LDK is light: ~10-20 MB RAM for a typical mobile node. Bitcoin Core
- LND can use 1+ GB. This is the main reason LDK dominates mobile.
Comparing LDK to LND/CLN
| Aspect | LND/CLN | LDK |
|---|---|---|
| Deployment | daemon | library, embedded |
| Mobile | no | yes (primary use) |
| Custom UI/logic | hard | easy (you own everything) |
| Default features | full | you choose |
| Memory | 200 MB+ | 10-20 MB |
Version floor and security history (as of September 2026)
LDK files no GitHub Security Advisories and cuts no GitHub Releases;
the ## Security sections of CHANGELOG.md are the advisory channel,
and a fresh patch release's entry lands on its tag before main.
Per-release detail, the 0.1/0.2 backport pattern and the lockfile
mechanics are in the companion Phase B article
knowledge/bitcoin/lightning/ldk/release-lines-deep.md.
- 0.2.6 (2026-09-09) is the floor on the 0.2 line. It fixes a
fee-inflation bug letting a malicious splice counterparty make us
over-allocate fee into their output when we contribute to a splice
(#4905), and a denial-of-service where a bogus HTLC rejected
immediately after a second HTLC with the same
payment_hashwas successfully forwarded could leaveChannelManagerin a state that fails deserialization — i.e. the node does not restart (#4982). - 0.2.5 and 0.1.12 (both dated 2026-08-04, published 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 while processing an un-revoked counterparty's claim, resolving them incorrectly (#4854). The same releases fixed several remote-panic DoS vectors — oversized protocol messages, invalid onion-message reply paths naming us as introduction point, reorg-time claim batching — and the limit of 50 peers with unfunded channels not being enforced against anopen_channelflood. Reported by Project Loupe and Kyle W. Santiago. - 0.2.3 / 0.1.10 (2026-06-18) are superseded but worth knowing:
anchor-reserve underestimates that could leave a node unable to
force-close properly,
possiblyrandomnot generating random data unless explicitly configured (HashDoS by default), and several remotely-triggerable panics. Most of it credited to Project Loupe. - The 0.1 line got no backport of the 0.2.6 fixes — v0.1.12 is still the newest 0.1 tag as of September 2026, so it remains the floor on the 0.1 line. #4905 is splice-only and 0.1 has no splicing, so it has no 0.1 counterpart; upstream says nothing either way about whether #4982 reaches 0.1.
ldk-node0.7.0's manifest requireslightning = "0.2.0", 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. Thelightning-*satellite crates are separately versioned and must move as a set.
Migrating to 0.3 (release candidate as of September 2026)
lightning 0.3.0-rc1 (2026-08-31) 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 examined in 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 issues
Persisttrait misimplementation: missed updates → state corruption on restart.- Async signer race conditions: signing requests racing with channel updates.
- Chain sync gaps: skipped blocks → channel state diverges.
- ldk-node migration: upgrading minor versions sometimes requires state migration; back up first.