BOLT12 (Offers)

BOLT12, commonly called "Offers," is a Lightning Network payment protocol that introduces a reusable, static payment code in place of the single-use invoices defined by BOLT11. An offer can be encoded as a QR code or a short string beginning lno1 and reused indefinitely, which makes it well suited to donations, tips, subscriptions, and any situation where one fixed code should accept many payments. It is the first new BOLT specification merged into the official Lightning standard since 2017 — a genuinely rare event in a protocol family that moves deliberately.

How offers improve on BOLT11

A traditional BOLT11 invoice is valid for one payment of one amount and expires, so a merchant must generate a fresh invoice for every transaction — which in turn requires a server, a web endpoint, or manual effort at payment time. An offer flips the flow: the static code is not itself an invoice but a standing instruction for how to request one. The payer's wallet sends an invoice_request to the offer's node over the Lightning Network itself, using onion messages, and the node replies with a fresh, one-time BOLT11-style invoice that the payer then pays normally. No website, no extra server, no out-of-band channel — the Lightning Network doubles as the invoice-delivery mechanism. Offers also natively support refunds (an offer can describe a payment the issuer will make, not just receive) and recurring-payment workflows.

Privacy through blinded paths

Offers lean on blinded paths, a routing technique in which the recipient constructs the final hops of the route toward itself and encrypts them, so neither the payer nor intermediate nodes learn the recipient's node identity or network position. A BOLT11 invoice necessarily embeds the recipient's node public key; an offer need not, which makes the static code far safer to publish permanently on a website or profile. For anyone whose threat model includes being mapped — a donation address on a controversial project, a merchant who prefers not to advertise channel topology — this is the headline feature, not a footnote.

Offers and Lightning addresses

BOLT12 is often mentioned alongside the human-readable Lightning address (user@domain), which today is typically implemented via LNURL — a web-server-based protocol that fetches invoices over HTTPS. The two solve the same "give people one reusable thing to pay" problem with different trust anchors: LNURL depends on a web server that can see and correlate requests, while offers keep the whole negotiation inside Lightning's encrypted onion messaging. Work on resolving human-readable identifiers directly to offers narrows the usability gap from the BOLT12 side.

The operational requirement hiding in the design is availability: because the invoice is fetched over onion messages at payment time, the recipient's node must be reachable when the payer asks. For an always-on node in the closet — the normal sovereign setup — that is no constraint at all, and it is a far lighter requirement than running a public web server. Mobile and intermittently online wallets bridge the gap with helper infrastructure from their Lightning Service Provider, and receiving still requires the usual inbound liquidity regardless of how the invoice was delivered. An offer replaces the web stack, not the node underneath it.

Adoption and practical use

As of 2026 the protocol is supported by Core Lightning, LDK, and Eclair/Phoenix, with wallet support broadening steadily. For a sovereign node runner the appeal is concrete: publish one string once — on a site, in a README, engraved on the workshop wall — and receive payments for years without touching a web stack, while your node's identity stays behind blinded paths. Offers build on the same channel and onion-routing machinery as the rest of Lightning; for other payment-delivery mechanisms, see our entries on Keysend and Trampoline Routing.