BOLT12
BOLT12 is the Lightning Network protocol for offers, invoice requests, and invoices that are fetched over the Lightning network rather than encoded as a static BOLT11 string. An offer is a compact, often reusable QR that the payer uses to request a fresh invoice, optionally via blinded paths that hide the recipient's node. BOLT 12 is specified in the Lightning BOLTs repository as the offer encoding and negotiation documents.
BOLT11 invoices are static: they fix a payment hash and usually an amount, they expose the destination public key, and they grow long when many routing hints are attached. Recurring or merchant payments need a reusable handle that still yields a unique preimage per payment. Onion messages and blinded paths (BOLT 4 extensions) made it possible to deliver an invoice request without publishing the recipient's location in the invoice. BOLT12, led by Rusty Russell and others, defines offers (lno...), invoice requests, and invoices as TLV streams with Merkle-tree signatures, carried over Lightning onion messages.
An offer contains a description, optional amount, issuer fields, feature bits, and either an issuer node id or blinded paths to the issuer. It is encoded as a Bech32 string beginning with lno and may be reused. A payer constructs an invoice request that includes the offer fields it is responding to, a payer key, an amount if the offer left it open, and a blinded path back to the payer for the reply. The request is sent as an onion message to the issuer. The issuer returns a BOLT12 invoice with a unique payment hash, amount, created-at time, relative expiry, and one or more blinded paths for the HTLC payment so the payer need not learn the recipient's node id. The invoice is signed with a Merkle-root signature scheme over TLV fields. The payer then sends an ordinary Lightning payment (HTLC, possibly multi-path) along the blinded path.
Blinded paths wrap hops in an onion the payer cannot fully inspect, which improves receiver privacy relative to BOLT11's cleartext destination. Reusable offers do not reuse payment hashes. Amount can be chosen at request time, which supports tips and donations. Proof of payment remains a preimage until PTLCs change that. Onion messages require network support; if a path cannot carry them, the payer cannot fetch an invoice from the offer. Implementations may also fetch invoices over HTTP for the same TLV types, but the native path is Lightning. Related receive UX includes Lightning address and LNURL.