LDK development has moved to Forgejo. You can still find the code on GitHub, where it will stay in sync. Release notes: 0.1.13: git.rust-bitcoin.org/lightni… 0.2.7: git.rust-bitcoin.org/lightni… 0.3-rc3: git.rust-bitcoin.org/lightni… 4/4

LDK 0.3 is getting close. It adds splicing improvements, async signing, LSPS1 service support, and BOLT 12 payer proofs. Please test rc3 and read the compatibility notes before upgrading. 3/4

Thanks to @ProjectLoupe, @nishant282003, and Erick Cestari for reporting these issues. 2/4

LDK 0.1.13, 0.2.7, and 0.3-rc3 are now available, with fixes for several security vulnerabilities, including fund theft. If you run LDK in production with untrusted channel counterparties, we recommend upgrading today. If you’re testing 0.3, update to rc3. 1/4

LDK Server is still in pre-release, but you can already manage a node with an AI agent. ldk-server-mcp exposes every node RPC as a tool over MCP — Claude Code, Codex CLI, Goose or any MCP client. Ask "which channels are low on outbound liquidity?" instead of doing the math ⬇️

1/ New releases: LDK 0.1.12 and 0.2.5 are on crates.io with a handful of security fixes from our ongoing code review efforts. Release notes have the full rundown ⬇️

No custodian. No capacity tied up across the network. Async payments are in beta (LDK-to-LDK for now) and ready to explore: 📖 Blog: lightningdevkit.org/blog/asy… 🛠️ Integration guide: lightningdevkit.org/async-pa…

2/ With async payments, an often-offline node (like the phone in your pocket) can receive Lightning payments without: 🚫 trusting a custodian with your funds 🚫 locking up network liquidity An LSP holds a static invoice and relays the release message until you're back online.

1/ Receiving a Lightning payment has always meant being online at the right moment. That assumption breaks down on mobile, where your app often can't wake up to claim an incoming payment. Async payments fix this👇

LDK's modularity was the key. Custom persistence for encrypted remote storage, transaction-based syncing, and a meganode design that shares the network graph across hundreds of users for a 10-100x memory win. Read the full case study: lightningdevkit.org/blog/lex…

New on our blog: @lexeapp is running self-custodial Lightning nodes inside Intel SGX secure enclaves. The result? Always-on nodes that send & receive 24/7. How they pulled it off 👇

👀

It's ready to test today. LDK Server is in preview — try it out, break things, and tell us what's missing. Bug reports and feature requests welcome. github.com/lightningdevkit/l…

2/ What's inside: • BOLT 12, splicing, zero-fee commitments, async payments • Built-in LSP(S) support (LSPS2 today, LSPS5 coming) • Postgres, Docker, Prometheus, Tor, gRPC • Runs without a full node via esplora/electrum + RGS • MCP server so AI agents can manage your node

1/ In case you missed the announcement from @benthecarman, we are releasing a production-grade Lightning node for servers. Everything that powers the likes of @CashApp, @Square, @moneydevkit, @lightspark, @lexeapp, and @getalby is packaged as a daemon anyone can run.

Get started with VSS today. Using it is straightforward, as VSS is already integrated with LDK Node v0.4.x+ github.com/lightningdevkit/v…

VSS uses client-side encryption and robust authorization. When a user loses a device, it can facilitate a seamless recovery. Multi-device access will be enabled in the future.

VSS keeps users’ funds more secure by automatically storing and backing up the lightning state in the cloud. Whenever there is a lightning state update, it is written to VSS before being finalized.