Encyclopedia Upgrades and scaling · Entry 215
BOLT 12 offers: reusable Lightning requests and fresh invoices
In this article
At a glance
Key facts
One published offer can lead to many invoices
The specification’s user-pays-merchant flow begins with an offer on a page or QR code. Each user asks for a unique invoice, which the merchant returns before payment. An offer can therefore outlive an individual invoice without asking everyone to reuse the same payment hash.
Offers may include constraints such as amount, supported chain, quantity or expiry. Reusable does not mean unconditional, permanent or payable by every Lightning wallet.
Two purchases should not become one shared invoice
Suppose a merchant publishes an offer for a 5,000-satoshi item. Two customers use the same offer, but their wallets request separate invoices. Each customer checks the returned invoice and authorizes their own payment.
If one request fails because the merchant is unavailable, the offer’s continued visibility does not show that payment succeeded. The request-and-response stage still has to complete.
Keep offers distinct from names and payment receipts
A Lightning Address uses a domain-based LNURL-pay service to obtain invoices. BOLT 12 defines its own offer, invoice-request and invoice objects. Similar reusable payment experiences do not make those protocols interchangeable.
The specification also discusses evidence that an invoice was paid and evidence tied to the requesting payer. Ordinary knowledge of a payment preimage alone does not prove a particular person paid. Preserve the actual wallet record instead of treating the public offer as a receipt.
Direct answers
Questions people ask
Is a BOLT 12 offer itself a paid invoice?
No. It contains information used to request an invoice. The wallet must obtain and validate the returned invoice, then complete the payment.
Does BOLT 12 support imply automatic recurring charges?
No. A reusable offer lets someone request additional invoices. It does not by itself grant a merchant authority to debit a wallet repeatedly without the payer’s payment process.
Inspect the evidence
The answer and key facts have stable claim links. These records retain the scope and qualification when reused.
A BOLT 12 offer is a reusable invitation to request a Lightning invoice. In the normal flow, a wallet reads the offer, sends an invoice request over Lightning messaging, receives a specific invoice and pays it. The offer and the invoice are different objects. Both sides need compatible support, and publishing an offer does not guarantee that its service is online or a payment route is available.
Educational explanation. Product-specific behavior is scoped to the cited documentation, checked 2026-10-02.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimOffer: Longer-lived information for requesting invoices
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimInvoice request: Asks for the particular payment terms
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimInvoice: Supplies the specific payment request
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimRevision history
- — First publication after primary-source research and separate automated verification.
Source register
Sources and references
Retrieval dates and locators are recorded individually.- BOLT 12: Negotiation Protocol for Lightning PaymentsLightning specification contributors
Reusable offers produce separate invoice requests and authenticated invoices.
Locator: Limitations of BOLT 11; Payment Flow Scenarios; Offers; Invoice Requests; Invoices; Payer Proofs · Version / scope: Pinned BOLTs revision · Retrieved: 2026-10-02T18:53:57.136ZOpen source - Sending PaymentsLightning Labs
LND initiated/in-flight/succeeded/failed statuses and safe retry semantics.
Locator: Pathfinding; Dispatching Payments; Payment Fees; Monitoring Payments · Version / scope: Pinned Lightning Labs documentation revision; LND/Loop implementation scope · Retrieved: 2026-10-02T18:53:57.437ZOpen source - Pay to static internet identifiersLNURL contributors
Lightning Address resolution to a domain-hosted LNURL-pay endpoint.
Locator: Paying to internet identifiers: username/domain resolution to LNURL-pay; metadata text/identifier versus text/email · Version / scope: LUD-16 pinned revision · Retrieved: 2026-10-02T18:53:57.523ZOpen source - LNURL-payLNURL contributors
HTTP callback, amount bounds, metadata and invoice verification in LNURL-pay.
Locator: LNURL-pay: metadata and amount response, invoice callback and wallet verification steps · Version / scope: LUD-06 pinned revision · Retrieved: 2026-10-02T18:53:57.478ZOpen source
Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.
Editorial method and correctionsDegrees of Satoshi editorial project. “BOLT 12 offers: reusable Lightning requests and fresh invoices.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/lightning-bolt12-offers/