NotATether: Create BOLT12 stub (offers / invoice requests)

2026-09-12T09:39:01Z

Create BOLT12 stub (offers / invoice requests)

New page

'''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 (<code>lno...</code>), 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 <code>lno</code> 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 [[Hash Time Locked Contracts|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 [[PTLC]]s 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]].

== See also ==
* [[BOLT11]]
* [[Lightning Network]]
* [[Hash Time Locked Contracts]]
* [[PTLC]]
* [[Lightning address]]
* [[LNURL]]

== External links ==
* [https://github.com/lightning/bolts/blob/master/12-offer-encoding.md BOLT 12: Negotiation Protocol for Lightning Payments]
* [https://github.com/lightning/bolts/blob/master/04-onion-routing.md BOLT 4: Onion Routing Protocol]
* [https://bolt12.org/ bolt12.org]

[[Category:Technical]]
[[Category:Privacy]]

BOLT12 - Revision history

NotATether: Create BOLT12 stub (offers / invoice requests)