# lnd: what the Lightning Network Daemon actually gives you > lnd is a full Lightning Network node in Go, with gRPC and REST APIs for building payment applications on top of it. It is beta software, and the README says ignoring the operational safety guidelines can lose funds. **lightningnetwork/lnd** — Lightning Network Daemon ⚡️ - Repository: https://github.com/lightningnetwork/lnd - Stars: 8,196 · Forks: 2,296 - Language: Go - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/lightningnetwork-lnd ## Who lnd is for, and the problem it removes Running a Lightning node by hand means tracking channel states, watching for the exceptional cases where a counterparty goes offline or broadcasts an old commitment, maintaining a validated channel graph, and finding routes across it. lnd takes that work on. The README describes it as a complete implementation of a Lightning Network node that can create channels, close them, manage all channel states including the exceptional ones, maintain a fully authenticated and validated channel graph, perform path finding, forward incoming payments passively, and send outgoing onion-encrypted payments. The audience is not end users. It is developers and operators. The README states the daemon was designed to be as developer friendly as possible to facilitate application development on top of it, and it exports two primary RPC interfaces: an HTTP REST API and a gRPC service. If you want a wallet with a screen, lnd is the layer underneath that wallet, not the wallet. If you are writing the wallet, the exchange integration, or the routing service, lnd is the target. ## Chain back ends and how a payment actually moves lnd does not talk to Bitcoin directly. It has pluggable back-end chain services: btcd, a full node; bitcoind; and neutrino, which the README calls a new experimental light client. That choice determines your resource profile more than anything else in the stack, because the chain back end is what feeds lnd its view of the chain. The codebase is built on the btcsuite set of Bitcoin libraries. On top of that, the payment path is the standard Lightning one. lnd maintains the channel graph, does path finding within it, forwards incoming payments passively, and sends outgoing payments as onion-encrypted messages through the network, using the lightning-onion package. It also updates advertised fee schedules, so a routing node's prices are a live part of its operation rather than a config file you set once. Autopilot is available for automatic channel management, which the README lists as a capability rather than a default. The protocol surface is defined by the BOLTs. The README claims full conformance and lists BOLT 1, 2, 3, 4, 5, 7, 8, 9, 10 and 11 as checked, covering the base protocol, peer protocol for channel management, transaction and script formats, onion routing, on-chain transaction handling recommendations, P2P node and channel discovery, encrypted and authenticated transport, assigned feature flags, DNS bootstrap, and the invoice protocol. Note what that list means in practice: BOLT 11 invoices are the ones you can rely on here. The repository also contains bolt12/ and amp/ directories, but the README's compliance list stops at BOLT 11, so do not read those directories as a compatibility promise. ## Installing lnd and sending a first payment The README does not put build steps inline. It points to docs/INSTALL.md for building from source and to docs/DOCKER.md for running from Docker. The Dockerfile in the repository builds a final Alpine image, copies /go/bin/lnd and /go/bin/lncli into /bin/, declares a volume at /root/.lnd for data persistence, and exposes ports 9735 (p2p) and 10009 (rpc). Those two port numbers are the ones to remember when you wire up firewalls or container networks. The Dockerfile accepts a checkout build argument, defaulting to master, so you can pin the image to a tag or commit instead of tracking the branch tip. The relevant lines are: ```dockerfile ARG checkout="master" ARG git_url="https://github.com/lightningnetwork/lnd" ``` The final image copies both binaries from the builder stage, which is how lncli ends up next to the daemon: ```dockerfile COPY --from=builder /go/bin/lncli /bin/ COPY --from=builder /go/bin/lnd /bin/ ``` And it declares the data volume and the two ports: ```dockerfile VOLUME /root/.lnd EXPOSE 9735 10009 ``` Once lnd is running, lncli is the client. It is installed alongside the daemon by the same Makefile target the Dockerfile invokes, make release-install, which is why both binaries appear in the image. A first real use is asking the node what it is: which network it is on, whether it has synced, and what identity it presents to peers. That call goes over the gRPC interface on port 10009 by default. The README does not spell out the lncli invocation for this, so check the RPC documentation at api.lightning.community before you script it. From there, the two operations that define a Lightning node are opening a channel and paying an invoice; the README lists both creating and closing channels as core capabilities, and the docker/ directory contains a step-by-step send payment guide. The REST and gRPC surfaces are documented at api.lightning.community, with guides and example applications at docs.lightning.engineering. ## The API stability warning is not boilerplate The README says the exported APIs are not yet stable and warns that they may change drastically in the near future. That is an unusual thing for a project this size to leave in its front page, and it should shape how you build against it. If your integration calls gRPC methods directly, treat every lnd upgrade as a potential breaking change and read the release notes before you move. The published releases show the pattern: v0.21.3-beta and v0.20.4-beta were both tagged on 2026-09-02, meaning two release lines are being maintained in parallel, with v0.21.3-beta.rc1 tagged on 2026-08-30. You need to know which line you are on and why. The second limitation is stated just as plainly. The README says lnd is still beta software and that ignoring the operational safety guidelines can lead to loss of funds. There is a docs/safety.md for mainnet operation. This is the wrong tool for anyone treating it as a set-and-forget service. Channel management has failure modes that cost money, and the exceptional channel states the README mentions are exactly the ones where an operator who has not read the safety document gets hurt. The third boundary is the light client. neutrino is described as experimental. If you pick it to avoid running a full node, you are accepting an experimental component in the path that tells your node what the chain looks like. ## How lnd compares with Core Lightning The obvious alternative is Core Lightning, the C implementation of the same BOLT specifications. Both are Lightning nodes; the difference is in what surrounds them. lnd is written in Go, uses the btcsuite libraries, and presents its functionality primarily as gRPC with a REST gateway, which suits developers embedding a node in a service and generating clients from the protobuf definitions. Core Lightning is a C daemon with a plugin architecture, and its extension model is built around plugins and a JSON-RPC interface rather than a protobuf service definition. That difference matters at the edges. If your team writes Go and wants to link against Lightning libraries rather than shell out to a daemon, lnd exports a large set of isolated re-usable Lightning Network related libraries, and the README calls that out explicitly. If your team wants to extend node behaviour with plugins in whatever language, the plugin model is the more natural fit. Neither is a quality ranking; they are different integration surfaces for the same protocol. ## Maintenance, releases and the MIT licence The repository is not archived, and the last push was on 2026-09-21, one day before this writing. Releases are frequent and versioned with a -beta suffix, and the parallel v0.20.4-beta and v0.21.3-beta tags indicate backported maintenance for operators who cannot jump minor versions immediately. The Makefile pins GO_VERSION = 1.27.1 and notes it is the reference version for the release build, the Docker files and GitHub Actions, with other Go versions checked against it. The Dockerfile repeats that version in its builder stage and carries a comment asking anyone who changes it to update GO_VERSION in the Makefile and run make lint. The practical upgrade cost is therefore not just the daemon: it is the Go toolchain, the chain back end, and any gRPC clients you generated. lnd is MIT licensed. That is a permissive licence, and the repository ships a LICENSE file at the top level. This is not legal advice, but the licence question is genuinely simple here compared with the operational one: the risk in running lnd on mainnet is not the licence, it is channel and key management. ## Conclusion Adopt lnd if you are building payment applications on top of a Lightning node, or you need a node you can drive through the gRPC and REST APIs rather than a GUI. Do not adopt it if you expect stable APIs, or if you are not prepared to read docs/safety.md before touching mainnet, because the README states that ignoring those operational guidelines can lead to loss of funds. Before you commit, verify three things: whether the RPC surface you depend on has shifted between v0.20.4-beta and v0.21.3-beta, which chain back end you will run (btcd, bitcoind or the experimental neutrino light client), and what your channel backup and restore path looks like, since chanbackup/ and chanrestore.go exist but the README does not document rollback. ## FAQ ### What is the Lightning Network Daemon (lnd)? lnd is a complete implementation of a Lightning Network node written in Go. It creates and closes channels, manages channel states, maintains a validated channel graph, does path finding, forwards incoming payments and sends outgoing onion-encrypted payments. ### Is lnd free to use? The repository is MIT licensed and ships a LICENSE file at the top level, so the software itself carries no fee. The costs that remain are operational, such as running a chain back end and the on-chain fees involved in opening and closing channels. ### Which wallets use the Lightning Network? The README does not list wallets. It positions lnd as the daemon that applications are built on top of, exposing REST and gRPC APIs, with guides and example applications at docs.lightning.engineering. ## Sources - [Issues](https://github.com/lightningnetwork/lnd/issues) - [License: MIT](https://github.com/lightningnetwork/lnd/blob/master/LICENSE) - [lightningnetwork/lnd on GitHub](https://github.com/lightningnetwork/lnd) - [README](https://github.com/lightningnetwork/lnd/blob/master/README.md) - [Releases](https://github.com/lightningnetwork/lnd/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lightningnetwork-lnd