lightning-bolt12BOLT12 offers: reusable invoices, blinded paths, recurring payments, multi-asset (Taproot Assets layered). Replaces BOLT11 for many use cases. USE WHEN: implementing/integrating offers, designing recurring payments, evaluating BOLT11 vs BOLT12 trade-offs.
Independent GitHub snapshot · Automated classification · Original documentation governs
BOLT12 is a flexible payment protocol that addresses BOLT11's limitations:
BOLT12 offers a static, reusable identifier (the "offer") that lets payers fetch a fresh invoice each payment via Lightning's onion message system.
lno1...) — long-lived, signed by recipient. Encodes:
lnr1...) — payer sends via onion message,
asks for an invoice for this offer.lni1...) — receiver responds with one-time invoice.
Standard payment proceeds.All three types use the BOLT11-style bech32 encoding with lno1,
lnr1, lni1 prefixes (no chain prefix; chain encoded in TLV).
Unlike BOLT11's tag/data tuples, BOLT12 uses pure TLV everywhere. Future-proof; new fields don't break old parsers.
Offers can include blinded paths — partial routes that hide the recipient's node id. The offer is signed by an "introduction node" + blinded route data; recipient is anonymous to the payer.
Offers can specify recurrence:
quantity_min: 1, quantity_max: 100
recurrence: monthly for 12 months
Same offer used for subscription: payer fetches a fresh invoice each month.
BOLT12 + Taproot Assets together enable invoices priced in non-BTC assets routed over LN. Recipient gets BTC amounts; payer pays in asset terms; intermediate hops handle conversion.
An lno1... string is too long to read aloud or type. Two specs
turn it into a human-readable identity; a third identifies the
payer instead:
Complete in the
BIPs repo as of September 2026. Publishes a BIP 21 URI, usually
just bitcoin:?lno=<offer>, in a DNSSEC-signed TXT record at
<user>.user._bitcoin-payment.<domain>, displayed as
₿user@domain. No HTTP endpoint in the path, unlike LNURL-pay
/ LUD-16; see the lightning-address skill.Active in
lightning/blips as of September 2026. Lets a client that cannot
validate DNSSEC itself ask a node over onion messages:
dnssec_query (type 65536) → dnssec_proof (65538), or
dnssec_error (65550).Active in lightning/blips as of September
2026. Adds optional invoice_request TLVs that let a payment
identify its payer: invreq_contact_secret (2000001729), plus
either invreq_payer_offer (2000001731) or
invreq_payer_bip_353_name (2000001733) with
invreq_payer_bip_353_signature (2000001735) proving control of
the offer behind that name. The recipient can then add the payer
as a contact and pay them back with no extra round trip.| Use case | BOLT11 | BOLT12 |
|---|---|---|
| One-time payment with known amount | yes | yes |
| Static "donate to me" QR code | hacky (LNURL-pay) | native |
| Recurring subscription | manual | native |
| Refund flow | no | yes |
| Hidden destination | no | yes (blinded paths) |
| Multi-asset | no (need TAP/RGB) | yes |
| Implementation | Send | Receive | Recurring |
|---|---|---|---|
| CLN | yes | yes | yes |
| LDK | yes | yes | partial |
| LND | partial | partial | no |
| Eclair | yes | yes | partial |
| phoenixd | yes (receive especially) | yes | partial |
lno1... as a single-use invoice → it's not, can be
reused.option_onion_messages feature
bit) → can't fetch invoice request response.invreq_payer_offer /
invreq_payer_bip_353_name from a payer you already hold a
contact_secret for → the spec says ignore them for known
contacts, so a leaked secret can't redirect your future payments
to an impostor's offer.