Lightning Network & Layer 2

Lightning Invoices Explained: BOLT11 and BOLT12

Feb 12, 2026 · 16 min read · Updated Latest correction
Lightning Invoices Explained: BOLT11 and BOLT12

A Lightning invoice is the mechanism that makes Lightning Network payments possible. Every time you scan a QR code to pay someone over Lightning, your wallet ends up with an invoice: the QR code is either the invoice itself (BOLT11) or a reusable code, such as a BOLT12 offer or an LNURL, that your wallet uses to request a fresh one. The invoice 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), or lnbcrt (regtest)
  • Amount: The payment amount, encoded in the string (e.g., lnbc500n = 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.
  • Payment secret: A second random value, separate from the preimage. Only someone who holds the invoice knows it, and the recipient rejects payments that do not carry it, so nodes along the route cannot test which node is the recipient. Every BOLT11 invoice must include one.
  • Destination (payee node ID): The public key of the recipient’s Lightning node. It is usually not written out: your wallet recovers it from the signature.
  • 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
The example invoice from the BOLT 11 specification, lnbc2500u1pvjluez…fna3rh, cut into its pieces. lnbc: the prefix, Lightning on Bitcoin mainnet. 2500u: the amount, 0.0025 BTC or 250,000 sats. 1: the separator. pvjluez: the timestamp, 1 June 2017. Then fields that each start with a letter that names them, followed by two characters for their length: s, the payment secret, which proves the payer has the invoice and is not the preimage; p, the payment hash, the lock on the payment; d, the description, 1 cup coffee; x, the expiry, 60 seconds, or 1 hour if left out; 9, the features the recipient's wallet supports. Then the signature, which proves who made the invoice and reveals their node ID, and a checksum that catches a mistyped character. The amount is written in bitcoin plus a letter: m milli, u micro, n nano, p pico, so 10n is 1 sat.
A BOLT11 invoice is one string made of fields. This is the specification’s own example: 0.0025 BTC for a coffee. Of its 271 characters, the signature takes 104 and the payment secret and payment hash 55 each, so even a plain invoice is long. Optional fields, such as routing hints, are not in this one.

How a BOLT11 Payment Works

  1. The recipient generates a random 32-byte secret (the preimage).
  2. The recipient hashes the preimage to produce the payment hash and encodes it into a BOLT11 invoice.
  3. The recipient shares the invoice with the sender (QR code, text, NFC, etc.).
  4. The sender’s wallet decodes the invoice, reads the destination and amount, and finds a route through the network.
  5. 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).
  6. 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.
How a BOLT11 payment works, in three steps. 1, the recipient keeps a secret, the preimage, and puts only its hash in the invoice, which reaches you as a QR code or text: the hash is a lock that only the preimage opens. 2, your payment moves hop by hop from you through two nodes to the recipient, and each hop is locked to that hash: it pays out for the preimage, or goes back after a deadline. 3, to get paid the recipient reveals the preimage; it travels back along the route, every lock opens and every hop is paid. Once paid, the invoice is used up, and a new payment needs a new invoice.
The payment hash is a lock; the preimage, which only the recipient knows, is the key. Every hop holds your payment under that lock (a hash time-locked contract, or HTLC) and gets paid when the preimage comes back. If it never does, the time lock sends the payment back. The same mechanism carries BOLT12 payments too.

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 reusable payment code. Here is the flow:

  1. 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.
  2. The sender scans or pastes the offer.
  3. The sender’s wallet sends an invoice request directly to the recipient’s node via an onion-routed message.
  4. The recipient’s node automatically generates a unique invoice in response and sends it back to the sender.
  5. The sender’s wallet pays the invoice using the standard HTLC mechanism.

The key difference: the offer itself contains no payment hash, and an amount is optional. 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.

How a BOLT12 offer works. The offer, a string starting lno1, holds how to reach the recipient's node and, if the recipient adds them, a description and an amount. It holds no payment hash, and it is published once, on a website, a profile or a printed card. 1, you scan it. 2, your wallet sends an invoice request to the recipient's node as an onion message over Lightning. 3, the node replies with an invoice made for this payment, with its own payment hash. Steps 2 and 3 are the extra round trip. 4, you pay it, locked to that hash, just as with BOLT11. For the next payment you use the same offer and go back to step 2 for a new invoice.
An offer is not an invoice: it tells your wallet where to ask for one. Your wallet requests a fresh invoice over Lightning for every payment, so the same offer can be paid again and again.

BOLT12 Key Improvements

PropertyBOLT11BOLT12
ReusabilitySingle-useReusable (same offer, many payments)
Recipient privacyNode ID exposed in invoiceBlinded paths hide recipient identity
QR code sizeLarge (signed invoice with full data)Short if the offer names the recipient’s node (from 60 characters). Each blinded path adds about 250 characters or more, so a private offer can be as long as a BOLT11 invoice.
Offline generationNo (requires online recipient)Offer can be created offline, but recipient must be online when payment arrives
Recurring paymentsNot natively supportedNot in the merged spec. Recurrence was part of early drafts and is now an open proposal (bolts PR #1240)
Proof of paymentPreimage proves paymentPreimage proves payment. Since July 2026 the spec also defines payer proofs (prefix lnp), which let the payer prove they paid a specific invoice (bolts PR #1346, merged 27 July 2026)
Refund flowNo standard mechanismBuilt-in refund protocol

Blinded Paths: Hiding the Recipient

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.

Two routes from you to a recipient. With a BOLT11 invoice, your wallet sees every node up to the recipient, and the invoice reveals the recipient's node ID, here 03e715…, from the specification's example. With a BOLT12 blinded path, your wallet sees the route only up to an introduction node, a public node chosen by the recipient. The hops after it show only random-looking IDs: the recipient is one of them, but you cannot tell which, and it may add fake hops at the end to hide how far away it is. Payments still arrive, because each blinded hop can read only where to send them next.
A blinded path lets you pay someone without learning which node they are. The recipient builds the path and encrypts each hop’s directions; after the introduction node, you see only random-looking IDs. With BOLT11, every invoice names the recipient’s node.

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

Recurring payments are not part of BOLT 12 as merged. Recurrence was in early drafts of offers, but it was left out of the version merged into the specification in September 2024 (bolts PR #798), and the spec now lists “Re-add recurrence” under possible future extensions. The proposal to bring it back, bolts PR #1240, was still open on 3 November 2026.

If it is merged and wallets implement it, a subscription offer would specify a payment schedule (for example, monthly) and the payer’s wallet could send each payment at the set interval. That would remove the custom subscription layers developers build on top of Lightning today. Until then, any “subscription” you see over Lightning is built by the app, not by the protocol.

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: LND 0.21 (June 2026) added onion-message forwarding and pathfinding, the transport BOLT 12 needs, but still has no native offers (0.21 release notes; latest release v0.21.6, 30 October 2026). BOLT 12 message formats are being merged into LND’s main branch for the next major release, which was not out as of 3 November 2026. Until then, LNDK (v0.3.0, September 2025) adds offers to LND as a separate daemon.
  • 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 (user@domain.com 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.

Two ways to get a fresh invoice from a reusable payment code. With a Lightning address such as name@domain.com, built on LNURL, your wallet asks a web server at the recipient's domain over the web (HTTPS); the recipient's node makes the invoice and the server sends back a BOLT11 invoice. The server sits in the middle: it must be online and it sees each request. With a BOLT12 offer, lno1…, your wallet asks the recipient's node over Lightning, in an onion message, and the node sends back a BOLT12 invoice by itself, with no web server in between. Either way, you then pay the invoice over Lightning.
A Lightning address and a BOLT12 offer both hand you a fresh invoice for each payment. The difference is who answers: a web server for the address, the recipient’s own node for the offer.

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: Recurrence is not in BOLT 12 today; it is an open proposal. If it is added and wallets support it, subscribing to paid content or services over Lightning could 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 before the payment is sent: your wallet sends an invoice request and the recipient’s node sends back an invoice, each as a small onion message over Lightning.

What is a Lightning Address?

A Lightning Address looks like an email address (user@domain.com) 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.

Part of our free Bitcoin course: This topic is covered in depth in Lightning Channels and Routing: How Payments Find Their Path from the Lightning Network & Bitcoin Nodes course.

Related Articles

Filed under: Lightning Network & Layer 2

Continue Reading

← Back to All Articles