What Is BOLT 12 in the Lightning Network?

BOLT 12 is a proposed Lightning network upgrade enabling reusable payment offers, route blinding, and onion messaging. Learn how it works.

By Jonathan West · Updated October 2026

BOLT 12 is a proposed upgrade to the Lightning network that enables reusable payment requests called offers, route blinding for receiver privacy, and onion messaging for censorship resistance.

It decides whether you can hand out one reusable payment request instead of swapping a fresh invoice for every payment.

About bolt 12

BOLT 12 is a proposed upgrade to the Lightning network that enables reusable payment requests called offers, route blinding for receiver privacy, and onion messaging for censorship resistance. On its official documentation site, BOLT 12 explains that the specification allows users to set up reusable requests rather than generating a fresh invoice for every transfer. Under the classic BOLT 11 format, a receiver must generate an invoice per payment and pass it to the sender. BOLT 12 changes this interaction by letting a receiver show a single static QR code that payers can fetch invoices from repeatedly. Both the sender and the receiver must use software that implements the specification for these transfers to complete. A Lightning address is a separate standard designed to make payments simpler by presenting an identifier that looks like an email address. According to Lightning Address, the protocol lets you send money like you send emails, removing the requirement to scan a new QR code or request an invoice for every transfer. While BOLT 12 is an upgrade proposal for the native Lightning protocol, a Lightning address relies on standard web requests to fetch an invoice from an internet domain. That means a Lightning address depends on the provider hosting that domain being online when a sender starts a payment. BOLT 12 offers and Lightning addresses tackle the inconvenience of one-time invoices from different angles. BOLT 12 operates directly over Lightning peer-to-peer communication channels using onion messaging, which keeps the receiver's Internet Protocol (IP) address hidden. A Lightning address relies on domain names, meaning if you stop using a specific provider, you may need to hand out a new address to everyone who pays you. Neither system removes your underlying responsibility to manage your funds and protect your wallet. When using self-custodial software, you remain responsible for securing your cryptographic keys and backing up your wallet data. Reviewing the difference between peer-to-peer protocol proposals and domain-based addresses helps you pick the right payment workflow for your requirements. If you manage your own infrastructure, learning how to run a bitcoin node gives you direct control over the node implementations that experiment with these protocols.

How it actually works

Classic Lightning payments use BOLT 11 invoices, which require generating a fresh payment request each time someone transfers satoshis. Generating a new invoice for every payment forces receivers and senders to swap invoices or wallet identifiers out of band. According to BOLT 12, BOLT 12 introduces offers that function as reusable payment requests. An offer can be printed on a physical tip jar as a single QR code instead of forcing payers to endure a long wait for individual BOLT 11 invoices. BOLT 12 offers also support social integration, such as publishing a wallet payment code to a Nostr profile to receive zaps, and automatic withdrawals from an exchange to a self-custodial wallet (see what is a non-custodial wallet).

Receiver privacy improves under BOLT 12 through a mechanism called route blinding. Alongside route blinding, BOLT 12 relies on onion messaging to transmit invoice requests and responses across Lightning nodes. This onion messaging architecture provides censorship resistance by keeping the receiver IP address hidden.

The Lightning Address standard approaches static payments through web protocols rather than native onion messaging. A Lightning address formats payment destinations as `you@` followed by a provider domain, mirroring standard email naming conventions. The site notes that if you can send an email, you can send a transaction to a Lightning address. The protocol instructions allow receivers to set minimum and maximum payment sizes and let senders attach images or comments to transfers. Many applications issue these addresses, and users can self-host or run a bridge server in front of their own Lightning node. The project documentation compares this setup to using an email server such as Gmail for Bitcoin payments, meaning the sender relies on the provider domain being online to complete the invoice request.

Implementation across node software remains experimental and uneven across the Lightning ecosystem. According to developer notes published on BOLT 12, the Lightning Network Daemon (LND) does not yet support BOLT 12, though developers can run LNDK alongside an LND node to experiment with the feature. Core Lightning requires running the software with the `--enable-experimental-features` or `--enable-experimental-offers` configuration flag. The Eclair node software can pay an offer using the `payoffer` remote procedure call (RPC) command or generate an offer using its Tip Jar plugin. The Lightning Dev Kit (LDK) includes the ability to create and pay offers directly. Broader design documents for features outside the core BOLT specification are organized as Bitcoin Lightning Improvement Proposals (bLIPs) on the bLIPs repository, which notes that if a feature is intended to become universal or near universal across the network, it must be standardized as a BOLT.

Sender and receiver applications must both support the selected standard. If a sender wallet only recognizes classic BOLT 11 invoices, attempting to pay a BOLT 12 offer or a Lightning address will fail unless a fallback or bridge server translates the request into an invoice the sending application can process.

Start here

1Check your wallet software documentation to verify whether it supports BOLT 12 offers, Lightning addresses, or classic BOLT 11 invoices. Consult [BOLT 12](https://bolt12.org/) to see the technical specifications required for node interoperability.
2Verify whether the person sending or receiving the payment uses software that supports the same protocol. Both sender and receiver wallets must support the feature for the transaction to complete.
3Perform a small test transaction before relying on a static offer or new Lightning address for larger balances. Testing confirms that channel paths, route blinding, or provider servers resolve properly without unexpected routing failures.
4Maintain a fallback method by generating a standard BOLT 11 invoice if a payment partner uses an application that does not support experimental offers or web-based addresses.
5Identify which service provider hosts the domain name if you decide to receive payments using a Lightning address. If you stop using that provider, you will need to distribute a new payment address, and senders depend on that provider being online.
6Back up your private signing credentials and wallet configuration before enabling experimental features or testing new node software. You can review key management principles in [what is a private key and public key](/learn/what-is-a-private-key-and-public-key) and [what is a seed phrase](/learn/what-is-a-seed-phrase).
7Review node release notes and documentation before enabling experimental flags. Core Lightning requires specific experimental flags to activate offers, and LND requires running companion software such as LNDK for testing.

Strengths

BOLT 12 offers provide reusable payment requests, allowing receivers to present a single static QR code on a tip jar rather than generating a fresh invoice for every payer.
Route blinding provides increased receiver privacy.
Onion messaging delivers censorship resistance by transmitting payment data across peer-to-peer Lightning channels while keeping the receiver IP address hidden.
Lightning addresses simplify the payment experience by using familiar email-style formats that allow senders to attach comments and images while respecting minimum and maximum payment limits.
BOLT 12 supports automated workflows including exchange auto-withdrawals to self-custodial wallets and publishing static payment codes to Nostr profiles for zaps.

Common misunderstandings

BOLT 12 remains a proposed upgrade to the Lightning network, meaning network-wide adoption is not yet universal across client software.
Node software support is uneven, as LND does not support BOLT 12 natively without running companion tools like LNDK, while Core Lightning requires experimental configuration flags.
Lightning addresses introduce domain dependencies, meaning you may need a new address if you leave your provider, and senders rely on the provider web server staying online.
Sender and receiver software must both support the specific standard used, causing payments to fail if one party only recognizes standard BOLT 11 invoices.
Consumer wallet support is not universally available.

Common questions

What is BOLT 12?

BOLT 12 is a proposed upgrade to the Lightning network that introduces reusable payment requests called offers. According to BOLT 12, the specification enables reusable payment requests, increased receiver privacy through route blinding, and increased censorship resistance through onion messaging. Unlike standard BOLT 11 invoices that work only once, a BOLT 12 offer can be displayed indefinitely, allowing payers to fetch new invoices directly over the Lightning network without exposing the receiver IP address.

What is a Lightning address?

A Lightning address is a standard that translates Bitcoin payments into an email-like identifier such as `you@` followed by a provider domain. According to Lightning Address, the protocol lets users send transactions as easily as sending an email, bypassing the need to generate invoices or scan fresh QR codes manually. The standard allows receivers to define minimum and maximum payment amounts and accept attached comments or images from senders.

Is BOLT 12 the same as a Lightning address?

BOLT 12 is not the same as a Lightning address. BOLT 12 is a proposed native Lightning protocol specification that uses onion messaging and route blinding directly over payment channels to request and fulfill invoices. In contrast, a Lightning address uses standard internet domain protocols to communicate with a web server that generates an invoice for the sender. A Lightning address depends on domain availability and host uptime, whereas BOLT 12 communicates entirely within the peer-to-peer Lightning network.

What is the difference between BOLT 11 and BOLT 12?

The primary difference is that BOLT 11 invoices are single-use payment requests, while BOLT 12 offers are reusable identifiers. With BOLT 11, a receiver must generate a new invoice for each individual transfer. With BOLT 12, a receiver can publish a single static offer code, such as a QR code on a tip jar, and payers can repeatedly request fresh invoices through onion messaging while keeping the receiver IP address hidden.

Does my wallet support BOLT 12?

In node software, implementation remains partial and experimental per BOLT 12. LND does not support BOLT 12 natively, though developers can test it using LNDK alongside their node. Core Lightning requires the `--enable-experimental-features` or `--enable-experimental-offers` flag. Eclair supports paying offers with the `payoffer` RPC command or creating them via its Tip Jar plugin, and LDK supports both creating and paying offers. For mobile setups, check our review on is zeus wallet safe and our broader guide on lightning network wallets.

Do I need a node to use a Lightning address?

You do not necessarily need to run your own node to use a Lightning address. Per Lightning Address, many hosted applications and custodial or self-custodial services issue addresses to their users directly. However, users who run their own infrastructure can self-host the protocol or use a bridge server in front of their own Lightning node. The protocol relies on simple instructions, functioning much like an email server that routes messages to your specific mailbox.

Sources

Ready to put this into practice?

Exchange sign-up bonuses pay both you and a referrer after a qualifying trade.

See bonuses →