LND (Lightning Network Daemon)

What Is LND?

LND (Lightning Network Daemon) is a full implementation of a Lightning Network node. It handles everything a Lightning node needs to do: connecting to peers, opening and closing payment channels, creating and paying invoices, routing payments, and monitoring for potential channel breaches. Written in Go and released under the MIT license, LND was developed by Lightning Labs, co-founded in 2016 by Elizabeth Stark and Olaoluwa Osuntokun. The first beta shipped in March 2018.

Among the three major Lightning implementations (LND, Core Lightning, and Eclair), LND holds the largest share of the network. Its widespread adoption stems from a combination of factors: comprehensive documentation, a rich API surface, mobile support via Neutrino, and inclusion as the default Lightning node in most node-in-a-box solutions. For developers building Lightning-powered applications, LND is often the first implementation they encounter.

How It Works

LND operates as a daemon process that sits between a Bitcoin chain backend and the applications that want to use Lightning. Its architecture has three main layers: the chain backend for on-chain awareness, the core daemon for channel and payment logic, and the API layer for external interaction.

Chain Backends

LND needs a source of Bitcoin blockchain data to verify transactions and monitor for channel closes. It supports three pluggable backends:

• bitcoind: Bitcoin Core integration via ZeroMQ for real-time event notifications. This is the most common production configuration, pairing LND with a full Bitcoin node.
• btcd: a full Bitcoin node written in Go, also maintained by Lightning Labs. It offers tighter integration since both projects share the same language and codebase conventions.
• Neutrino: a lightweight client using compact block filters (BIP 157/158). Rather than downloading the entire blockchain, Neutrino fetches only the block headers and filters relevant to the wallet. This makes it practical for mobile devices and resource-constrained environments.

Core Components

Inside the daemon, several subsystems handle different responsibilities:

• Wallet: manages on-chain funds, UTXO selection, transaction creation, and signing. Supports SegWit and Taproot address types.
• HTLC Switch: the routing engine that forwards HTLCs between channels. It handles onion decryption, manages the lifecycle of each HTLC, and interacts with individual channel links.
• Mission Control: tracks payment success and failure history per channel to inform future routing decisions. This probabilistic model improves pathfinding accuracy over time.
• Channel State Machine: manages the lifecycle of each channel from opening through cooperative or force close, including revocation and breach remediation via justice transactions.

API and Authentication

LND exposes its functionality through a gRPC interface defined by Protocol Buffers. A REST gateway mirrors every gRPC endpoint as an HTTP/JSON call. The API is organized into subservers, each covering a domain:

# Core subservers
Lightning    — channel ops, payments, invoices, peer management
WalletKit    — on-chain wallet operations, UTXO management
Router       — payment routing, mission control, fee estimation
Invoices     — hold invoices, invoice subscriptions
Signer       — signing operations, PSBT handling
ChainNotifier — on-chain event subscriptions
Watchtower   — breach monitoring (client and server)
Autopilot    — automatic channel management

Authentication uses macaroons: bearer credentials that support delegation and attenuation. LND generates three default macaroons on startup: admin.macaroon (full access), readonly.macaroon (read-only queries), and invoice.macaroon (invoice creation only). Developers can bake custom macaroons with restricted permissions for specific use cases. Transport security is handled via TLS.

Interacting with LND

The command-line tool lncli wraps the gRPC API for direct interaction:

# Check node info
lncli getinfo

# Open a channel with 1M sats
lncli openchannel --node_key=<pubkey> --local_amt=1000000

# Create an invoice
lncli addinvoice --amt=50000 --memo="Payment for services"

# Pay an invoice
lncli payinvoice <bolt11_invoice>

# Check channel balances
lncli channelbalance

For application development, gRPC client libraries are available in most languages. The protobuf definitions can generate native clients for Go, Python, JavaScript, Java, Rust, and others. The Node.js library ln-service is particularly popular for web application backends.

The LND Ecosystem

Lightning Labs has built several complementary tools around LND that extend its capabilities beyond basic channel management:

Lightning Loop

Loop is a non-custodial service for managing channel liquidity via submarine swaps. Loop Out moves funds from Lightning to an on-chain address, freeing up inbound liquidity. Loop In does the reverse, converting on-chain funds into Lightning channel balance. Combined with Autoloop, nodes can maintain target liquidity levels automatically.

Pool

Pool is a non-custodial marketplace where node operators buy and sell inbound channel liquidity. Operators with excess capital can lease their liquidity to those who need it, creating a market-driven pricing mechanism for channel capacity.

Taproot Assets

Formerly known as Taro, Taproot Assets is a protocol for issuing arbitrary assets on Bitcoin using Taproot outputs. Asset metadata is embedded within existing UTXOs using Schnorr signatures. These assets can be transferred over Lightning channels, enabling instant, low-fee movement of stablecoins and other tokens on Bitcoin's Layer 2. The separate tapd daemon runs alongside LND to handle asset operations.

Lightning Terminal

Lightning Terminal (litd) bundles LND with Loop, Pool, Faraday (a channel analytics tool), and Taproot Assets into a web-based dashboard. It provides a GUI for node management, making it more accessible for operators who prefer visual interfaces. Lightning Node Connect (LNC) enables end-to-end encrypted remote connections to the node, even behind Tor or NAT.

LND vs Other Implementations

Three major open-source implementations of the Lightning Network exist, each conforming to the same BOLT specifications but differing in architecture, language, and philosophy.

LND's monolithic design means features are built into the core binary rather than added via plugins. This simplifies deployment but limits extensibility: adding custom behavior requires waiting for upstream changes or maintaining a fork. Core Lightning takes the opposite approach with a plugin architecture that lets developers extend functionality without modifying the core. Eclair, written in Scala, is battle-tested at scale through ACINQ's operation of one of the network's largest routing nodes. For a deeper comparison, see the node implementation comparison.

Why It Matters

LND's dominance shapes the Lightning Network in practical ways. When the vast majority of nodes run the same implementation, its feature support and release timeline effectively set the pace for what the network can do. Features like keysend payments, anchor outputs, and Simple Taproot Channels reached widespread availability largely because LND shipped them.

For developers building Lightning applications, LND's ecosystem offers the most complete toolkit: from the channel management APIs to Loop for automated liquidity, to Taproot Assets for multi-asset payments. The mobile SDK (LND compiled via gomobile with a Neutrino backend) has made Lightning accessible on phones, powering wallets like Blixt. The breadth of the Lightning service provider ecosystem built on LND reflects this tooling advantage.

Layer 2 solutions like Spark expand the scaling landscape beyond Lightning, but LND remains the most widely deployed infrastructure for Bitcoin payment channels today.

Risks and Considerations

Implementation Monoculture

When over 90% of nodes run the same software, a critical bug in LND could affect nearly the entire network. Software diversity is a resilience strategy: if multiple implementations share the network load, a bug in one affects only a fraction of nodes. The Lightning community has long discussed this concentration risk, though LND's market share has remained dominant.

Resource Requirements

Running LND with a full Bitcoin Core backend requires significant disk space, memory, and bandwidth. The channel graph database (recently migrated to SQL in v0.20) can grow large on well-connected nodes. While Neutrino reduces these requirements for mobile and lightweight use cases, it trades off some verification guarantees compared to a full node.

Operational Complexity

Operating an LND node effectively requires ongoing attention: fee management, channel rebalancing, liquidity planning, and software updates. A force close due to misconfiguration or downtime can lock funds for days. Operators should understand watchtower configuration and backup procedures before running a production node. The routing deep dive covers the economics of running a routing node.

Feature Lag in Some Areas

LND's monolithic architecture means that some features arrive later than in competing implementations. BOLT12 offers and splicing are areas where Core Lightning and Eclair have shipped more complete support. LND has introduced partial solutions (blinded paths for invoice privacy in v0.20) while full BOLT12 support continues in development.

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.