We're excited to announce the release of LND v0.21! Fittingly, our latest release lands on a number that bitcoiners know well, a nod to the 21 million bitcoin supply cap, and this release is something of a coming-of-age moment for LND. This release brings privacy-preserving onion message support to LND for the first time, graduates simple taproot channels to a production-ready feature, and continues our journey of moving LND's data stores onto a native SQL backend. Together, these changes lay the foundation for a more private, more capable, and more performant Lightning Network. Some of the release highlights include:

• Basic onion messaging support, a privacy-preserving way for nodes to send messages through the network without revealing the sender or route, introduced via a new peer-to-peer message type. This paves the way for advanced privacy features and future protocol upgrades like BOLT 12 offers.
• Production-ready simple taproot channels with the finalized taproot channel scripts, optimized signature checks, and RBF cooperative close support. This sets the stage to finalize taproot gossip, eventually leading to public taproot channels.
• Payment store migration to native SQL, continuing the data store modernization journey, for better performance and scalability.
• Fast initial sync for Neutrino nodes which cuts the initial sync for a fresh light-client node from hours to minutes on mainnet, by bootstrapping its block and filter headers from a file or URL instead of fetching them one at a time from peers.

As always, we are grateful for the ongoing support of our external contributors and community across development, review, and testing. For the complete list of changes included in this release, check out the full release notes.

Onion Messaging Arrives in LND 🧅

Onion messages are a privacy-preserving way for Lightning nodes to send messages to one another through the network without exposing the sender or the route the message follows. This is the same mechanism that powers BOLT12 offers, a Lightning specification for reusable invoices. With v0.21, LND can now forward onion messages on behalf of its peers, taking its first step toward becoming a full participant in the messaging layer for BOLT12.

For node operators, this means your node can now relay these private messages for its peers, helping the network move toward features like BOLT12 invoice requests, improving receiver privacy for BOLT12 offers. The idea builds on something Lightning already does: today, payments are routed using onion encryption, where each node in the path peels back a single layer to learn only the next hop, never the full route or the original sender. Onion messaging applies that same routing technique to standalone messages that aren't tied to a payment, so nodes can pass information through the network with the same sender and route privacy that payments already enjoy. Because these messages aren't attached to a channel update, relaying one is lightweight: there's no commitment transaction and no on-chain footprint.

Since your node relays these messages on behalf of others, LND ships with sensible defaults so the feature can't be abused at your expense. Messages from peers without an open channel are dropped by default, so only peers that have committed capital can use your node as relay infrastructure, and per-peer and global rate limiters cap how much traffic any peer can drive. Operators who want to accept messages from all peers can opt in via protocol.onion-msg-relay-all=true, with the rate limiters still applied. For the full adversary model, defaults, tunable flags, and operator recipes, see the onion messaging rate limiting section on the LND repo.

Simple Taproot Channels Are Ready for Production 🌱

Simple taproot channels bring the privacy and efficiency benefits of taproot to Lightning channel funding. By using taproot key-path spends, the on-chain footprint of a Lightning channel can look indistinguishable from any other taproot transaction, improving privacy for all Lightning users. With v0.21, this graduates from its previous experimental status to a production-ready feature, meaning taproot channels are now safe to use on mainnet with the finalized channel scripts (feature bits 80/81).

Taproot channels also now support the RBF (Replace-By-Fee) cooperative close protocol via --protocol.rbf-coop-close, which lets you bump the fee on a stuck, unconfirmed cooperative close transaction, just like you can on legacy channels. Behind the scenes this uses MuSig2, a scheme for combining multiple signatures into one, with careful handling to prevent nonce reuse across fee-bump attempts. Being able to raise the fee on a stuck close transaction is a meaningful quality-of-life improvement in volatile fee environments.

The SQL Migration Continues 🗄️

Continuing our quest to make node operations more performant and scalable, v0.21 migrates the payments database to native SQL. For node operators, this means faster, more scalable payment-history queries. Under the hood, this release introduces a payment store interface, implements the SQL schema with query and insert methods, threads context through the payment DB layer, and adds the KV-to-SQL payments migration.

Users already on postgres or sqlite backends with --db.use-native-sql set will have their payments migrated automatically on startup. As with the SQL migrations in previous versions, nodes still on bbolt, the key-value (kvdb) database LND has historically used, can use the lndinit tool to migrate to sqlite or postgres first to take advantage of these new capabilities.

For nodes that have completed the migration to postgres or sqlite, we've measured over 97% wall-time reduction on the ListPayments RPC for large databases after migrating over to native SQL. If you've been holding off the DB migration for performance reasons, this is a good release to commit to the move. We encourage operators who haven't already, to run the migration process with this release and see the gains firsthand.

Faster Sync for Neutrino Nodes ⚡

If you run LND in Neutrino mode, the light-client backend that works without a full Bitcoin node, spinning up a fresh node used to mean waiting hours while it fetched block and filter headers one at a time from peers. With v0.21, a new node can instead bootstrap those headers from a local file or HTTP(S) URL on first startup, cutting initial sync on mainnet from hours to minutes. Imported headers are still validated for proof-of-work, and once the import finishes the node falls back to normal peer-to-peer sync to reach the chain tip.

Quality-of-Life and Usability Improvements 👍

This release also brings several updates designed to make day-to-day node management more convenient and to add additional safety margins to operations.

Safer Channel Closes: Channel closes now require between 3 and 6 confirmations instead of being finalized immediately on spend detection. The requirement scales linearly with channel capacity up to the standard maximum and large "wumbo" channels (those above the standard capacity limit of ~16.7M sats) always require 6 confirmations. Waiting for confirmations protects your node against chain reorganizations: rather than acting the moment it sees a close, LND waits until the close is buried deep enough that a reorg is very unlikely to undo it, keeping your view of channel state consistent with the chain.

Faster Startup After Restart: The channel graph cache now loads asynchronously on startup. Queries are served directly from the database until the cache is ready, so LND becomes query-ready sooner after a restart. The previous behavior is still available via --db.sync-graph-cache-load.

Run Multiple Read-Only RPC Middlewares: LND lets external tools register as RPC middleware to observe your node's API traffic. Until now, only one read-only middleware could be registered at a time, which created a real conflict: if you ran Lightning Terminal, Lightning Labs' node management interface, its built-in logging middleware took the only slot, so you couldn't attach a read-only middleware of your own. v0.21 lifts that limit, so multiple read-only middlewares can run side by side, each independently observing RPC activity.

More Granular Forwarding History Management: The new DeleteForwardingHistory RPC on the router sub-server lets operators selectively purge old forwarding events. These events record the payments your node has routed for others, including amounts, timing, and the channels involved. Clearing them reduces the sensitive routing data your node keeps on hand, so less is exposed if your node or its data is ever compromised. Deletion requires a cutoff timestamp at least 1 hour in the past to prevent accidental removal of recent data.

The LND Release for 21 Million Bitcoin 🟠

The architectural advances in v0.21, namely onion messaging support, production-ready taproot channels, and the continued migration of LND's data stores to native SQL, are foundational steps toward a more private, more performant, and a more capable Lightning implementation. Onion messaging unlocks an entire category of future privacy-preserving features. Production taproot channels lay the groundwork for splicing and other advanced channel management workflows. And each step in the SQL migration journey moves LND further away from the kvdb data stores that have historically held back LND's performance at scale. Upgrade to v0.21 today to get all the benefits of the latest release.

We'd like to thank the entire community for their feedback on and contributions to this release, and we look forward to hearing from you. You can find us on the LND Slack, reach out to us on Twitter/X, contribute a PR, or subscribe to our newsletter.