A Lightning invoice is the mechanism that makes Lightning Network payments possible. Every time you scan a QR code to pay someone over Lightning, you are reading an encoded invoice that contains all the information your wallet needs to route the payment: the destination, the amount, the payment hash, an expiration time, and routing hints. Understanding how Lightning invoices work — and the differences between the BOLT11 and BOLT12 standards — gives you a clearer picture of how payments actually move through the network and why the protocol is evolving.
This guide explains both invoice formats at a practical level, covers their differences, and discusses what BOLT12 means for the future of Lightning payments.
What Is a Lightning Invoice?
A Lightning invoice is a payment request. Unlike an on-chain Bitcoin address where you send whatever amount you choose, a Lightning invoice typically specifies exactly how much to pay, where to send it, and how long the request remains valid. The recipient generates the invoice, shares it with the sender, and the sender’s wallet reads the encoded data to construct and route the payment.
The term “invoice” is precise — it is a request for a specific payment, not a persistent address. Once paid or expired, a standard Lightning invoice cannot be reused. This is fundamentally different from on-chain Bitcoin addresses, which can receive multiple payments over an indefinite time period.
BOLT11: The Current Standard
BOLT11 (Basis of Lightning Technology, specification #11) has been the dominant Lightning invoice format since the network’s early days. If you have used the Lightning Network at all, you have interacted with BOLT11 invoices — even if you only saw them as QR codes.
Anatomy of a BOLT11 Invoice
A BOLT11 invoice looks like a long string of alphanumeric characters, typically starting with lnbc (for mainnet Bitcoin) followed by encoded payment data. Here is what is packed inside:
- Network prefix:
lnbc(mainnet),lntb(testnet), orlnbcrt(regtest) - Amount: The payment amount, encoded in the string (e.g.,
lnbc50n= 50 satoshis). Can be omitted for “any amount” invoices. - Timestamp: When the invoice was created
- Payment hash: A 256-bit hash that the payment is conditional on. The recipient knows the preimage (the secret that hashes to this value); the sender does not. This is the cryptographic glue that makes multi-hop payments atomic.
- Destination (payee node ID): The public key of the recipient’s Lightning node
- Description: A human-readable description of what the payment is for (e.g., “Coffee at Shop X”)
- Expiry: How long the invoice remains valid (default: 1 hour, configurable)
- Routing hints: Suggested routes for reaching the destination, particularly useful when the recipient’s node is not well-connected to the public graph
- Signature: Cryptographic signature from the recipient, proving they created the invoice
How a BOLT11 Payment Works
- The recipient generates a random 32-byte secret (the preimage).
- The recipient hashes the preimage to produce the payment hash and encodes it into a BOLT11 invoice.
- The recipient shares the invoice with the sender (QR code, text, NFC, etc.).
- The sender’s wallet decodes the invoice, reads the destination and amount, and finds a route through the network.
- The payment travels hop by hop through intermediary nodes, each one holding funds conditional on receiving the preimage (these are Hash Time-Locked Contracts, or HTLCs).
- The final recipient reveals the preimage to the last hop, which reveals it back through the chain. Each hop resolves its HTLC, and the payment settles.
BOLT11 Limitations
BOLT11 has served the Lightning Network well but has several structural limitations:
- Single-use by design. Each invoice contains a unique payment hash. Once paid, it cannot be paid again. Merchants generating thousands of invoices for web checkout need a backend that creates fresh invoices for each customer — adding complexity.
- Recipient privacy leak. The invoice includes the recipient’s node public key. Anyone who sees the invoice knows which node is receiving the payment, which can potentially be linked to an IP address or real-world identity.
- Size. BOLT11 invoices are cryptographically signed and can be quite long, especially with routing hints. This makes them harder to display in compact QR codes that lower-quality cameras might struggle to read.
- No native reusability. Workarounds like LNURL exist to provide reusable payment endpoints, but these are add-on protocols, not part of the Lightning specification itself.
- Requires an online recipient. The recipient must be online to generate an invoice. If a merchant’s node is temporarily offline, no invoices can be created and no payments can be received.
BOLT12: The Next Generation
BOLT12 (also called “Offers”) addresses BOLT11’s limitations with a fundamentally redesigned payment flow. Proposed by Rusty Russell (Core Lightning developer), BOLT12 introduces a two-step request-response model that enables reusable payment codes, recipient privacy, and more flexible payment interactions.
How BOLT12 Offers Work
Instead of generating a single-use invoice, the recipient creates an offer — a compact, reusable payment code. Here is the flow:
- The recipient creates a BOLT12 offer and publishes it (on their website, social media, printed on a card, etc.). The offer is identified by a string starting with
lno. - The sender scans or pastes the offer.
- The sender’s wallet sends an invoice request directly to the recipient’s node via an onion-routed message.
- The recipient’s node automatically generates a unique invoice in response and sends it back to the sender.
- The sender’s wallet pays the invoice using the standard HTLC mechanism.
The key difference: the offer itself does not contain a payment hash or amount. It is just a lightweight pointer that says “contact this node to get an invoice.” The actual invoice is generated on demand, uniquely for each payment.
BOLT12 Key Improvements
| Property | BOLT11 | BOLT12 |
|---|---|---|
| Reusability | Single-use | Reusable (same offer, many payments) |
| Recipient privacy | Node ID exposed in invoice | Blinded paths hide recipient identity |
| QR code size | Large (signed invoice with full data) | Compact (offer is smaller) |
| Offline generation | No (requires online recipient) | Offer can be created offline, but recipient must be online when payment arrives |
| Recurring payments | Not natively supported | Native support for subscriptions |
| Proof of payment | Preimage proves payment | Preimage proves payment + payer can be identified if needed |
| Refund flow | No standard mechanism | Built-in refund protocol |
Blinded Paths: Privacy by Default
One of BOLT12’s most significant features is blinded paths. Instead of including the recipient’s node ID in the offer, the offer can contain a blinded route — a path where intermediate hops are encrypted so that only each hop knows the next step, not the final destination. The sender can route a payment to the recipient without ever learning the recipient’s node identity.
This is a meaningful privacy upgrade. With BOLT11, every invoice reveals the recipient’s node public key. Chain analysis firms and surveillance companies can build maps of which nodes receive payments. Blinded paths break this link, making Lightning payments more private at the protocol level.
Recurring Payments and Subscriptions
BOLT12 includes native support for recurring payments. A subscription offer can specify a payment schedule (e.g., monthly), and the payer’s wallet can automatically send payments at the defined interval. This eliminates the need for custom subscription management layers built on top of Lightning — a pain point for developers building paid services with BOLT11.
Current Adoption Status (2026)
BOLT12 support varies across implementations:
- Core Lightning (CLN): Full BOLT12 support. CLN was the first major implementation to support offers natively.
- Eclair (and Phoenix Wallet): BOLT12 support implemented. Phoenix can send and receive via BOLT12 offers.
- LND: BOLT12 support is under active development. LND has historically been slower to adopt BOLT12 compared to CLN and Eclair.
- LDK: BOLT12 support has been implemented, making it available to wallets built on the Lightning Dev Kit.
- OCEAN mining pool: Supports BOLT12 offers for mining payouts — miners can receive regular small payouts to their Lightning wallet via a reusable offer.
The adoption is progressing but not yet universal. Most users in 2026 still primarily interact with BOLT11 invoices. BOLT12 is gaining traction as implementations mature and wallets expose the feature in their interfaces. The backward compatibility of the Lightning protocol means both formats coexist — your wallet can support both BOLT11 and BOLT12 simultaneously.
LNURL: The Bridge Protocol
Between BOLT11 and BOLT12, the community developed LNURL — a set of protocols that add missing functionality to BOLT11 without changing the core specification. LNURL-pay provides reusable payment links. LNURL-withdraw enables pull payments. LNURL-auth enables login with Lightning. Lightning Addresses ([email protected] format) are built on LNURL-pay.
LNURL solved many of BOLT11’s limitations before BOLT12 was ready. However, LNURL requires a web server to mediate the interaction, which introduces a centralized point of failure and a potential privacy leak. BOLT12 achieves similar functionality natively at the protocol level without requiring external infrastructure.
The long-term expectation is that BOLT12 will gradually absorb many LNURL use cases, but LNURL will persist for backward compatibility and specific web-integration scenarios.
Practical Implications for Users
What does all this mean if you are a regular Lightning user, not a protocol developer?
- For paying invoices: Your wallet handles the technical details. Whether you scan a BOLT11 invoice or a BOLT12 offer, the payment experience is similar — scan, confirm amount, pay. Modern wallets like Phoenix support both formats transparently.
- For receiving payments: BOLT12 offers mean you can publish a single payment code on your website or social profile. Anyone can pay you multiple times using the same code — no need to generate fresh invoices for each transaction.
- For privacy: If privacy matters to you, prefer wallets and services that support BOLT12 with blinded paths. This prevents your node identity from being exposed in every payment request.
- For subscriptions: When BOLT12 recurring payments are widely supported, subscribing to paid content or services over Lightning will work natively without custom infrastructure.
Frequently Asked Questions
Can I use BOLT11 and BOLT12 at the same time?
Yes. Wallets that support both formats can send and receive using either. BOLT11 remains the fallback for interacting with wallets and services that have not yet adopted BOLT12. There is no conflict between the two — they coexist on the same Lightning Network.
Do I need to do anything to switch to BOLT12?
No active migration is needed. As your wallet software updates to support BOLT12, you will gain the ability to create and pay offers alongside traditional invoices. Check your wallet’s release notes for BOLT12 support status.
Are BOLT12 payments faster than BOLT11?
The payment itself moves at the same speed — both use the same HTLC routing mechanism. BOLT12 adds one extra round trip (the invoice request/response exchange) before the payment is sent, but this typically takes less than a second over the Lightning Network’s onion-routed messaging.
What is a Lightning Address?
A Lightning Address looks like an email address ([email protected]) and is built on LNURL-pay. When someone pays your Lightning Address, their wallet contacts a web server at your domain to fetch a BOLT11 invoice. It is convenient but requires a web server and does not provide the privacy benefits of BOLT12 blinded paths.
Will BOLT11 stop working?
No. BOLT11 is deeply embedded in the Lightning ecosystem and will remain functional for the foreseeable future. BOLT12 is an addition, not a replacement. The Lightning specification is designed for backward compatibility — new features coexist with existing ones.
Lightning Channels and Routing from the
Lightning Network & Bitcoin Nodes course.
