# BOLT 12 offers: reusable Lightning requests and fresh invoices 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. Evidence: [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md); [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) Canonical: https://degreesofsatoshi.com/encyclopedia/lightning-bolt12-offers/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:29:20.637Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Offer:** Longer-lived information for requesting invoices ([BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md)) - **Invoice request:** Asks for the particular payment terms ([BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md)) - **Invoice:** Supplies the specific payment request ([BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md)) ## 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. Evidence: [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) ## 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. Evidence: [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) ## 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. Evidence: [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md); [Pay to static internet identifiers](https://raw.githubusercontent.com/lnurl/luds/913c49e5b65081473eed7889eee5f806dd30f049/16.md); [LNURL-pay](https://raw.githubusercontent.com/lnurl/luds/913c49e5b65081473eed7889eee5f806dd30f049/06.md) ## Questions ### 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. Evidence: [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) ### 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. Evidence: [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) ## Claims and scope ### lightning-bolt12-offers-quick-answer 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: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-bolt12-offers-fact-offer Offer: Longer-lived information for requesting invoices Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-bolt12-offers-fact-invoice-request Invoice request: Asks for the particular payment terms Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-bolt12-offers-fact-invoice Invoice: Supplies the specific payment request Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) — Lightning 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. Retrieved: 2026-10-02T18:53:57.136Z. - [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) — Lightning Labs. LND initiated/in-flight/succeeded/failed statuses and safe retry semantics. Locator: Pathfinding; Dispatching Payments; Payment Fees; Monitoring Payments. Retrieved: 2026-10-02T18:53:57.437Z. - [Pay to static internet identifiers](https://raw.githubusercontent.com/lnurl/luds/913c49e5b65081473eed7889eee5f806dd30f049/16.md) — LNURL 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. Retrieved: 2026-10-02T18:53:57.523Z. - [LNURL-pay](https://raw.githubusercontent.com/lnurl/luds/913c49e5b65081473eed7889eee5f806dd30f049/06.md) — LNURL 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. Retrieved: 2026-10-02T18:53:57.478Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees 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/