Overview
BOLT12 is a proposed extension to the BOLT specification that introduces "offers" to the Lightning Network. An offer is a reusable, static payment request that can be encoded in a compact QR code or string, allowing a recipient to receive multiple payments over time without generating a new invoice for each one. Unlike LNURL, which achieves similar goals through HTTP callbacks, BOLT12 operates entirely within the Lightning protocol itself, requiring no external web server.
The limitations of traditional Lightning invoices (BOLT11) have long been a pain point for users and developers. Each BOLT11 invoice is single-use, contains the recipient's node public key (revealing their identity), and expires after a set time. BOLT12 addresses all of these issues by separating the concept of a persistent offer from the individual invoices generated in response to it.
How It Works
The BOLT12 payment flow involves a two-step process where the payer first fetches an offer, then requests a fresh invoice through the Lightning Network itself using onion messages:
Traditional BOLT11 Flow:
Recipient generates invoice ──► Payer decodes ──► Payer pays
(single-use, contains node ID)
BOLT12 Offer Flow:
1. Recipient publishes static offer (e.g., QR code)
2. Payer scans offer
3. Payer sends onion message to recipient: "I want to pay"
4. Recipient replies with fresh invoice via onion message
5. Payer pays the invoice
┌──────────┐ Onion msg: "invoice_request" ┌──────────┐
│ Payer │ ──────────────────────────────► │ Recipient│
│ │ ◄────────────────────────────── │ │
│ │ Onion msg: "invoice" │ │
│ │ ──────────────────────────────► │ │
│ │ Payment (HTLC) │ │
└──────────┘ └──────────┘
Because the invoice request and response travel through onion-routed messages within the Lightning Network, no HTTP server is required. The recipient's node handles everything natively.
Key Features
Reusable payment codes: A single offer can be used for unlimited payments. Merchants, content creators, and donation recipients can print a single QR code that works indefinitely.
Payer privacy: BOLT12 invoices can use blinded paths so that the payer does not learn the recipient's node public key. The recipient can also use blinded paths in the offer itself, hiding their node identity from everyone.
Refunds and recurring payments: The specification includes native support for refund flows and subscription-style recurring payments, which are cumbersome or impossible with BOLT11.
No web server dependency: Unlike LNURL, which requires an always-online HTTP endpoint, BOLT12 operates purely within the Lightning protocol layer. This improves decentralization and reduces the attack surface.
BOLT12 vs. LNURL
Feature BOLT12 Offers LNURL
────────────────────────────────────────────────────────
Reusable codes Yes Yes
Requires HTTP server No Yes
Payer privacy Blinded paths Depends on setup
Recipient privacy Blinded paths No (server IP exposed)
Refund support Native Limited
Recurring payments Native Limited
Adoption status Growing Widely deployed
Protocol layer Lightning native HTTP + Lightning
Both approaches solve real usability problems and are likely to coexist. LNURL has a significant head start in wallet adoption, while BOLT12 offers stronger privacy properties and better decentralization.
Current Status
BOLT12 has been implemented in Core Lightning (CLN) and is being adopted by other implementations. The specification is still evolving, with ongoing discussions in the Lightning development community about feature details and cross-implementation compatibility. As adoption grows, BOLT12 is expected to become a standard feature across all major Lightning wallets and node software.
Related Concepts
- BOLT — the specification framework that BOLT12 extends
- Lightning Invoice — the single-use invoice format (BOLT11) that BOLT12 improves upon
- LNURL — an alternative HTTP-based approach to reusable payment requests
- Blinded Paths — the privacy mechanism used by BOLT12 to hide sender and receiver identities
- Onion Routing — the transport layer for BOLT12 invoice request and response messages