B++ Logo
Feedback

BOLT12 & Lightning Offers

BOLT12 is a Lightning protocol extension that introduces offers (and related structures such as invoice requests and refunds) as a more flexible alternative to BOLT11 invoices. Offers allow payers to request an invoice from a payee without the payee having to be online first, support reusable payment identifiers, and enable use cases like recurring payments and better keysend-style flows.

BOLT11 vs BOLT12

AspectBOLT11 (Invoices)BOLT12 (Offers)
CreationPayee creates invoice when they want to be paidPayee creates offer (can be static, reusable)
AmountFixed at creation (or any for amount=any)Can be fixed or "any amount" in the offer
Payee onlinePayee typically online to create invoiceOffer can be published; payee only needs to be online when invoice is requested
ReusabilityOne invoice ≈ one paymentOne offer can yield many invoices (e.g., recurring)
EncodingBech32 (lnbc..., lntb...)Bech32 with lno/lnr/etc. prefixes

BOLT12 is specified in BOLT 12 and related BOLTs. Support is implemented in Core Lightning and LDK; LND and others are adding or have partial support.

Offers

An offer is a signed, self-describing payment request that:

  • Identifies the payee (node public key)
  • May fix an amount or allow any amount
  • Can specify metadata (description, chain, etc.)
  • Can require features the payer must support
  • Does not include a payment hash or invoice; those are created only when the payee generates an invoice in response to an invoice request

Offer String (BOLT12)

Offers are encoded as Bech32 strings with human-readable prefix lno (mainnet) or lnt (testnet/signet):

lno1pg257enxv4ezqcneype82um50yq...  (simplified example)

The payload is TLV-encoded and includes chain, amount (optional), description, node id, and signature.

Invoice Requests

To pay via an offer, the payer sends an invoice request to the payee. The invoice request:

  • References the offer (or its contents)
  • Can specify or refine the amount (if the offer allows any amount)
  • Can include payer metadata (e.g., for refunds or identification)
  • Is sent over the Lightning network to the payee’s node (or a Blinded Path)

The payee responds with a BOLT12 invoice (or a BOLT11 invoice if that’s what was negotiated). That invoice is then paid like any other Lightning payment (e.g., HTLC routing).

Keysend and Spontaneous Payments

Keysend (BOLT11-era) allows sending to a node public key without a pre-made invoice: the payer chooses the payment hash (and preimage) and the recipient must accept it. BOLT12 offers and invoice requests provide a more structured way to do “spontaneous” or “push” payments: the payer fetches an invoice (or an “any amount” invoice) from the payee via the offer protocol, so the payee controls the payment hash and metadata. This can reduce probing and improve privacy.

Recurring and Subscription Payments

Because offers can be reusable, a payee can publish one offer that generates a new invoice for each payment. Examples:

  • Subscriptions: Same offer each period; payer sends an invoice request with the period’s amount (or the offer specifies it), payee returns an invoice, payer pays.
  • Donations / any-amount: Offer with “any amount”; payer sends desired amount in the invoice request; payee returns an invoice for that amount.

Refunds

BOLT12 defines refund flow: the payee can issue a refund (a kind of offer or invoice that pays from the payee to the payer). This is useful when the payee needs to return funds (e.g., cancelled order, overpayment). Refund semantics and encodings are part of the BOLT12 suite.

Blinded Paths and Privacy

To request an invoice from an offer, the payer must reach the payee. BOLT12 can use blinded paths (onion-routed, blinded identifiers) so that the payer does not need to know the payee’s direct node id or IP. The offer can contain a blinded path to the payee, improving privacy.

Current Support

  • Core Lightning (CLN): Full BOLT12 support (offers, invoice requests, refunds).
  • LDK: Offer and invoice-request support for use in wallets and services.
  • LND: BOLT12 support is in progress or partial; check release notes.
  • Eclair: Check latest docs for BOLT12 status.

Wallets and merchants that support BOLT12 can publish offers (e.g., on the web, in apps) and accept payment once the payer requests an invoice and pays it.

Resources