Glossary

LDK (Lightning Dev Kit)

A flexible Lightning library that lets developers embed Lightning functionality directly into applications without running a standalone node.

Key Takeaways

  • LDK is a Lightning Network implementation packaged as a library, not a standalone daemon: developers embed it directly into their applications, gaining full control over storage, networking, and key management.
  • The modular architecture lets you bring your own components: swap in any blockchain data source, persistence layer, or networking stack using well-defined Rust traits. This makes LDK suitable for mobile wallets, web apps, and large-scale payment platforms.
  • Maintained by Spiral (Block, Inc.), LDK powers production Lightning in Cash App, Alby Hub, and other wallets, with language bindings for Rust, Swift, Kotlin, Python, and JavaScript. Unlike LND or Core Lightning, it treats Lightning as a feature you add rather than a service you run.

What Is LDK?

LDK (Lightning Dev Kit) is an open-source SDK that implements the full Lightning Network protocol as a composable library. Instead of running a separate Lightning daemon that your application communicates with over RPC, LDK compiles directly into your codebase. Your application becomes the Lightning node.

Written in Rust and dual-licensed under Apache 2.0 and MIT, LDK implements all BOLT specifications and has been in production since 2021. Spiral, the Bitcoin-focused open-source team within Block, Inc. (formerly Square), maintains the project with a dedicated engineering team.

The core insight behind LDK: most Lightning implementations were built for server environments, making them difficult to embed in mobile apps, web browsers, or custom infrastructure. LDK inverts this by providing Lightning as a library with pluggable interfaces, letting developers adapt it to any runtime environment.

How It Works

LDK's architecture centers on a set of Rust traits (interfaces) that define how the library interacts with external systems. Developers implement these traits to connect LDK to their chosen infrastructure, or use the default implementations provided for common setups.

Core Components

The main structs developers interact with:

  • ChannelManager: the central protocol engine that tracks open Lightning channels, HTLCs in flight, and handles peer reconnection
  • PeerManager: manages connections to other Lightning nodes, coordinating message passing with ChannelManager
  • ChainMonitor: watches the blockchain for relevant transactions and manages per-channel monitors that enforce on-chain security
  • NetworkGraph: stores the Lightning network topology for routing decisions
  • ProbabilisticScorer: scores payment paths based on historical success rates and channel capacities
  • KeysManager: provides cryptographic key material from a 32-byte seed, with support for custom implementations that delegate signing to hardware wallets or HSMs

Pluggable Interfaces

What makes LDK fundamentally different from LND and Core Lightning is its modular trait system. Each external dependency is abstracted behind a trait that developers implement:

  • Blockchain data: connect to Bitcoin Core RPC, Electrum servers, Esplora, or compact block filters (BIP 157/158)
  • Persistence: store channel state to local disk, SQLite, cloud storage (iCloud, Google Drive), a remote database, or any key-value store
  • Networking: use the default TCP socket implementation, pipe messages over WebSocket for browser environments, or even route Lightning protocol messages over USB to a signing device
  • Fee estimation: provide your own fee rate estimates for different confirmation targets via the FeeEstimator trait
  • Transaction broadcasting: implement how transactions reach the Bitcoin network through the BroadcasterInterface trait

Event-Driven Architecture

LDK uses an event-driven model. When you initiate an action like sending a payment, the call returns immediately. LDK later notifies your application of the outcome through events. A simplified integration looks like this:

// Initialize LDK with your chosen components
let channel_manager = ChannelManager::new(
    fee_estimator,
    chain_monitor,
    broadcaster,
    router,
    logger,
    keys_manager,
    user_config,
    chain_params,
);

// Process events in your application loop
loop {
    let events = channel_manager.get_and_clear_pending_events();
    for event in events {
        match event {
            Event::PaymentClaimable { payment_hash, amount_msat, .. } => {
                // Decide whether to claim the payment
                channel_manager.claim_funds(payment_preimage);
            }
            Event::PaymentSent { payment_hash, .. } => {
                // Payment succeeded: update your application state
            }
            Event::PaymentFailed { payment_hash, .. } => {
                // Payment failed: notify user or retry
            }
            _ => {}
        }
    }
}

LDK Node: A Higher-Level Wrapper

For developers who want Lightning functionality without deep protocol knowledge, the LDK team also maintains LDK Node. While raw LDK exposes over 900 methods, LDK Node simplifies this to roughly 30 API calls by making opinionated choices about architecture.

LDK Node integrates BDK (Bitcoin Dev Kit) for on-chain wallet management, includes built-in persistence via SQLite, and supports rapid gossip sync for mobile-optimized network graph updates. It generates language bindings via UniFFI for Swift, Kotlin, Python, and Flutter/Dart.

Language Bindings

LDK's Rust core generates bindings for multiple languages, enabling integration across platforms:

LanguageMechanismPrimary Use Case
RustNativeServer infrastructure, custom nodes
Java / KotlinAutogenerated bindingsAndroid wallets, JVM servers
SwiftC bindings + UniFFIiOS wallets
PythonUniFFI (LDK Node)Scripting, prototyping
JavaScript / TypeScriptWASM bindingsBrowser wallets, web apps
Flutter / DartUniFFI (LDK Node)Cross-platform mobile apps
C / C#C bindings / autogeneratedSystem-level integrations

LDK vs. Other Lightning Implementations

The Lightning Network has three major implementations. Each takes a fundamentally different approach to how developers integrate Lightning functionality. For a deeper comparison, see the node implementation comparison.

AspectLDKLNDCore Lightning
ArchitectureLibrary embedded in your appStandalone daemon with gRPC/REST APIStandalone daemon with plugin system
LanguageRustGoC
PhilosophyLightning as a featureLightning as a serviceLightning as a modular server
Mobile suitabilityDesigned for mobile from the startServer-focusedServer-focused
Key managementFully customizable (HSM, hardware wallet)Built-in walletBuilt-in wallet with HSM plugin
CustomizationSwap any component via traitsConfiguration files and APIPlugin architecture

The key tradeoff: LND and Core Lightning give you a working node out of the box. LDK gives you building blocks that require more integration work but offer far greater flexibility. For mobile wallets and embedded applications, this flexibility is essential.

Use Cases

Mobile Self-Custodial Wallets

LDK was specifically designed for mobile environments where running a full daemon is impractical. Its no_std support means the core library can run on resource-constrained devices. Features like rapid gossip sync minimize bandwidth consumption by compressing network graph updates for mobile clients.

Wallets like Bitkit and EttaWallet use LDK to provide self-custodial Lightning on mobile without compromising on user sovereignty. The persistence trait lets these wallets store channel state alongside their existing data layer.

Large-Scale Payment Platforms

Cash App, one of the largest payment apps in the United States, uses LDK for Lightning withdrawals and deposits serving millions of users. Their integration leverages Java/Kotlin bindings, phantom nodes for multi-server invoice handling, and custom pathfinding algorithms with background probing for reliability.

Browser-Based Lightning

LDK compiled to WebAssembly (WASM) enabled Mutiny Wallet to become the first self-custodial Lightning wallet running entirely in a web browser. This demonstrates LDK's portability: the same protocol implementation runs natively on servers, on mobile devices, and in browser sandboxes.

Federated Systems

Fedimint uses LDK for its Lightning gateway, connecting the federated ecash system to the broader Lightning Network. The modular architecture lets Fedimint plug LDK into its existing consensus and storage layers without running a separate daemon.

Why It Matters

LDK represents a shift in how developers think about Lightning integration. Rather than treating Lightning as an external service your application talks to, LDK makes it a native capability embedded in your code. This matters for several reasons:

  • Applications can ship Lightning as a feature alongside their existing functionality, without requiring users to manage separate node software
  • Custom key management enables advanced security models: hardware wallet signing, threshold signatures, or TEE-based key storage
  • The library approach scales from single-user mobile wallets to multi-server platforms processing millions of payments

For the broader ecosystem, LDK lowers the barrier to building Lightning-enabled applications. Projects like Spark and other Layer 2 solutions benefit from a growing set of Lightning-capable wallets and services, since deeper Lightning integration across the ecosystem improves liquidity and connectivity for all participants. For developers evaluating Lightning SDKs, the wallet SDK comparison provides a broader overview of available tooling.

Risks and Considerations

Integration Complexity

LDK's flexibility comes at a cost: developers are responsible for wiring together components that other implementations handle internally. Persistence must be implemented correctly to avoid channel state loss, networking must handle reconnection gracefully, and the event loop must process events promptly to avoid missed HTLCs or force closures.

LDK Node mitigates this for simpler use cases, but applications with custom requirements still face significant integration work. The mobile wallet architecture guide covers common patterns for handling these challenges.

State Management

Lightning channel state must be persisted atomically and reliably. If a node loses its latest channel state and broadcasts an outdated commitment transaction, the counterparty can claim all funds via a justice transaction. Since LDK delegates persistence to the developer, the burden of ensuring correct, crash-safe storage falls on the application.

Ecosystem Maturity

While LDK is production-ready and powers major platforms, its ecosystem of tooling and documentation is smaller than LND's. LND benefits from years of community-built tooling, tutorials, and operational knowledge. LDK's documentation has improved substantially, but developers may find fewer community resources for edge cases.

Rapid Evolution

LDK is under active development with frequent releases. The API surface can change between versions, requiring applications to update their integration code. The project reached its v0.1 milestone in January 2025, signaling growing stability, but breaking changes are still possible in the path toward a 1.0 release.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.