Lightning Dev Kit (LDK)

Lightning Dev Kit (LDK) is a complete Lightning Network implementation delivered as a software development kit rather than a standalone daemon. Built in Rust and stewarded by the LDK developers — a project supported by Spiral, Block's open-source Bitcoin unit — it lets builders embed Lightning directly inside their own applications, choosing and assembling the components themselves instead of running a separate node process alongside.

SDK versus full node daemon

Traditional implementations such as LND, Core Lightning, and Eclair ship as running node processes: you operate them, and your application talks to them over RPC. LDK inverts that. It provides the pieces — the channel state machine, gossip and routing, peer-to-peer messaging, on-chain monitoring logic — as libraries, and the developer supplies the surrounding decisions: where channel state persists, how networking is transported, where blockchain data comes from (a full node, an Electrum server, or compact block filters for mobile), and how keys are managed. This modularity is the point. Lightning can then run inside environments a daemon could never fit — a phone app that sleeps and wakes, a hardware signer, a point-of-sale terminal — or scale up inside server infrastructure, without forcing one fixed architecture on every use case.

Where it is used

LDK exposes bindings across multiple languages, so it integrates on iOS, Android, web, and server platforms. For teams that want the modularity without assembling every piece, the project publishes higher-level packages: LDK Node, a ready-made library for building self-custodial mobile wallets with sensible defaults, and server-oriented tooling for node-style deployments. Several large applications have shipped on LDK, including Cash App's Lightning support and tooling from Alby — meaningful production validation for an embedded approach.

Why embedded Lightning matters for sovereignty

The custodial shortcut has always been the easy path on Lightning: let a company run the node, hold the keys, and expose an app. LDK attacks the reason that shortcut exists. If a wallet developer can embed a real Lightning node in the app itself — channel keys on the user's device, chain data verified against the user's chosen source — then self-custody stops being a server-administration hobby and becomes an implementation detail. Users get self-custody without running a machine; developers get Lightning without reinventing the protocol. The remaining operational realities of Lightning still apply: channels need inbound liquidity to receive, offline devices need strategies such as watchtowers to guard channel state, and swaps bridge on-chain and off-chain balance.

Choosing between LDK and a daemon

It helps to see what LDK actually hands the developer. The core crates cover channel management and HTLC state machines, gossip processing and pathfinding, peer networking, and on-chain claim logic — the parts of Lightning where a subtle bug loses money and a decade of accumulated edge cases matters. What it deliberately does not decide is everything environmental: an iPhone app persists channel state very differently from a server with a database, and a wallet using BIP-158 filters watches the chain very differently from one attached to a full node. By drawing the line there, LDK lets each product make those calls while inheriting protocol correctness from a shared, heavily reviewed core. That separation is also why the SDK approach has aged well: as the protocol grows new features, they land once in the libraries and flow outward to every embedding application, instead of each wallet team re-implementing — and re-debugging — the same state machine in isolation.

LDK is one option among several ways to run Lightning, and the trade-off is honest: a daemon gives an operator a complete, battle-tested node with a mature ecosystem of dashboards and tooling; an SDK gives a developer control and embeddability at the cost of owning more decisions. Home node operators running a box built on RaspiBlitz or similar will usually meet Lightning through a daemon; app builders increasingly meet it through LDK. For the daemon-side management layer, see Lightning Terminal (litd), and for payment-layer standards see BOLT12 offers.