BOLT 12 is a Lightning payment negotiation protocol using an offer, an invoice_request and an invoice. An offer is reusable, but each payment has its own conditions and verified outcome.
The recipient publishes an offer; the payer sends invoice_request and receives a fresh invoice. Only then can payment follow. The offer can serve multiple people or repeated payments. Fetching an invoice, for example through fetchinvoice, does not pay it, and a published QR is not standing debit authorization. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 stores fields as TLV. Text offers use prefix lno and requests lnr; the alphabet resembles Bech32 but has no trailing checksum. The offer itself is unsigned. BIP340 Schnorr signatures in requests and invoices verify the Merkle root of their fields, not a merchant’s identity. [BOLT 12 — Negotiation protocol]
The wallet compares copied invoice_request fields with the invoice, amount, chain and signature. The invoice_node_id key must match offer_issuer_id or the appropriate final blinded_node_id. A valid unrelated signature is insufficient. The Merkle structure enables selective field proofs, not arbitrary changes to signed conditions. [BOLT 12 — Negotiation protocol]
Bitcoin invoice_amount is in msat; 1000 msat is one satoshi. An offer can specify another currency through offer_currency under ISO 4217; USD, for example, uses cents. Quantity and any conversion when the invoice is issued affect the price. If invreq_amount is specified, the invoice must match; otherwise the authorized range is checked. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths carries the request message; invoice_paths carries payment. A current invoice must contain blinded paths and matching invoice_blindedpay, even when a path goes directly to the recipient. Blinding reduces topology disclosure but does not promise complete anonymity, availability or liquidity. Requesting an invoice does not require an ordinary HTTPS payment server. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry limits use of the offer. invoice_created_at together with invoice_relative_expiry limits the particular invoice; without the latter field, 7200 seconds applies. A reusable offer therefore does not give invoices unlimited validity. Unknown even mandatory feature bits are rejected; unknown odd bits are ignored. [BOLT 12 — Negotiation protocol]
For a refund, the party wishing to send money can publish invoice_request without an offer. The money’s recipient replies with their own invoice; the payer must verify the intended recipient, out of band if needed. This is a new payment, not cancellation of the original. Scanning a request alone proves neither entitlement nor payment approval. [BOLT 12 — Negotiation protocol]
Keep the invoice, payment state and matching preimage. A preimage proves invoice settlement but does not by itself identify the human payer. After losing a response, check state before paying again. Offer support does not mean every extension or automatic recurring payment is supported; check receiving, sending and app authorization separately. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
For the clearest picture, read this entry together with BOLT 11, Lightning Network, Lightning Routing, Bitcoin Privacy, Satoshi, LNURL. The reverse links also lead from BOLT 11, LNURL, Rusty Russell.