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.
Offers
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.
Invoice fetch
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.
Deployment
Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.
Refunds and recurring subscriptions can reuse one offer while each invoice request still creates a fresh payment hash. Merchant software often stores the offer string in a QR or LNURL-style link and lets the wallet complete negotiation silently. Feature bits in the offer tell the payer which invoice fields and payment capabilities are required before it sends an HTLC. Nodes that do not support onion messages cannot fetch BOLT12 invoices even when they can pay BOLT11. Deployment therefore tracks onion-message and blinded-path support across major Lightning implementations.