A BOLT-12 Offer Is Not a Reusable Invoice

Receive-only tip jars want a sticky entry point: a flyer QR, a profile string, a bookmarkable link — not a merchant till. The earlier CryptoDecentral note on BOLT-11, inbound liquidity, and LNURL-pay covered the still-dominant pattern — mint a fresh invoice behind an HTTP(S) or Onion URL. BOLT #12 offers are the Lightning-native answer to the same stickiness problem.

Thesis, stated once: an offer (lno) is a precursor, not a reusable invoice. The payer sends an invoice_request (lnr) over a Lightning onion message; the payee replies with a one-shot BOLT-12 invoice (lni) that carries a unique payment_hash; payment proceeds as usual. Blinded paths (offer_paths / invoice_paths) hide the final node from the payer beyond an introduction point. This is protocol literacy for gratitude and tips — not a checkout stack.

Educational only. Verify against the BOLTs you are reading. Offer and onion-message support still varies — a network fact, not a wallet ranking.

What BOLT-11 could not do cleanly

BOLT #12 opens with an inventory of BOLT #11’s limits. Several matter directly for sticky tip jars:

1. Entangled Bech32 encoding made it awkward to carry invoices inside Lightning itself — so static reuse patterns leaked into HTTP LNURL and similar out-of-band minting.
2. payment_secret probing: the secret that stops forwarding nodes from casually probing the final recipient only helps if the invoice stays private between payer and payee. Paste a BOLT-11 string somewhere public and that protection weakens.
3. Per-user, one-shot danger: invoices must be given per user and are actively dangerous if two payment attempts are made for the same invoice. Treating a printed BOLT-11 QR as a permanent tip jar is misuse of the object, not “reuse with vibes.”

BOLT #11 remains the workhorse payment request. Offers do not abolish it; they relocate the sticky identifier one layer up so each payment still gets a fresh, unique hash.

The user-pays flow (tips shape)

BOLT #12’s general user-pays flow maps cleanly onto tips — the spec itself names tips, kudos, and donations as uses of offers without expecting something in return:

1. The recipient publishes an offer (web page, QR, profile field, printed card).
2. Every payer requests a unique invoice over Lightning using an invoice_request onion message that mirrors the offer fields.
3. The recipient replies with an invoice.
4. The payer pays that invoice.

There is also a merchant-pays-user flow (ATM / refund); tip jars live in the first. Either way the long-lived object is the offer; the payable object is a fresh invoice with its own invoice_payment_hash. Onion messaging is the transport: if the recipient is offline or unreachable, there is no invoice to pay — an honest constraint, not a marketing footnote.

Encoding literacy: lno / lnr / lni

Each BOLT-12 form is a TLV stream. ASCII encoding is: human-readable prefix + 1 + bech32-style TLV data. There is no trailing checksum (unlike bech32m). QR codes already carry integrity; a corrupted offer fails closed as unreadable rather than sending funds wrong. Writers SHOULD use uppercase in QR codes and lowercase elsewhere. Large strings MAY insert + (optionally followed by whitespace) between bech32 characters so the payload can split across limited text fields — readers MUST strip those.

Prefix	Object	Role for tips
lno	offer	Sticky precursor you publish
lnr	invoice_request	Payer → payee over onion message
lni	invoice	One-shot request with unique hash

Signature TLV elements occupy types 240–1000. Offer non-signature fields use 1–79 (plus a large experimental band); invoice-request fields including mirrored offer fields use 0–159; invoice fields extend through 0–239. Those ranges exist so offer fields can be mirrored into the request and then the invoice without colliding — the offer node can stay relatively stateless, with offer_metadata available as an authentication cookie.

Offer fields that matter for tip jars

For variable tips, BOLT #12’s own rationale is the checklist:

• Omit offer_amount (and therefore offer_currency). When amount is absent, the payer MUST set invreq_amount. That is the “any amount” tip shape.
• offer_description is optional for tips. Description is vital when charging for something specific; optional when money is sent without expecting something in return.
• offer_issuer is especially useful for tips — a clear UTF-8 issuer string (often user@domain or a domain, optionally with more text).
• MUST set offer_issuer_id OR offer_paths. Readers MUST NOT respond if neither is present. Private-only channel topologies MUST include offer_paths from publicly reachable introduction nodes.
• offer_absolute_expiry lets a long-lived tip offer still die cleanly; after expiry, readers MUST NOT send invoice requests.

Quantity max, multi-chain offer_chains, and ISO-4217 offer_currency matter more for priced goods. Tip literacy starts with sticky lno, no fixed amount, clear issuer, and a reachable path or issuer id.

Blinded paths: introduction point visible, rest hidden

Route blinding is how offers and invoices can give recipient anonymity without a second network. At high level:

• The recipient chooses an introduction point and a route from that point to itself.
• Subsequent hops are blinded (ECDH-derived public keys); encrypted per-hop data tells each real node how to forward.
• The payer sees the real node_id of the introduction point and blinded identifiers afterward — not the real ids of the hidden hops.

The blinding proposal lists recipient anonymity for BOLT-12 offers, recipient anonymity when receiving payments, and using unannounced channels without revealing them. BOLT #12 requires invoices to include invoice_paths plus matching invoice_blindedpay aggregates. If privacy is not needed, a length-1 path (just the recipient) is explicitly allowed — the protocol still forces a blinded-path shape so features stay uniform.

For tip offers, offer_paths is how a privately channelled node stays reachable: onion invoice_requests must travel via a published path. Honest constraint again: the recipient must be online and reachable to answer. Blinded paths hide topology from the payer; they do not create asynchronous voicemail for Lightning invoices.

Still receive-only literacy

None of this repeals inbound liquidity. A perfect offer that mints a perfect lni still fails if channels cannot accept the amount — the same physics covered in the prior receive-only note. Offers change how the sticky entry point negotiates a fresh hash; they do not mint remote balance.

Onion-message and offer support is uneven across implementations — state that without ranking products. Some stacks speak offers; others still centre BOLT-11 plus LNURL-style HTTP minting. Read which features counterparts actually advertise.

Dependency shape (civil liberty)

Where this framing travels: small gratitude and mutual-aid signals already live under high-friction rails — platform freezes, weekend cutoffs, intermediary politics. LNURL-pay solves sticky QRs by putting an HTTP(S) or Onion host in the trust path: that host can refuse to mint, go dark, or rewrite policy. BOLT-12 relocates minting onto Lightning onion messages along blinded paths. The dependency question becomes: who can unilaterally refuse the thank-you — a web host operator, or the channel and messaging topology you already accepted when you chose non-custodial receive?

That is not “replace the remittance industry.” It is a narrower claim about signal-path dependency for tips. Match the tool to the threat model you wrote down.

What this note deliberately does not do

It does not rank wallets, LSPs, or Lightning service providers. It does not sell merchant processors or POS funnels. It does not discuss prices, yields, submarine swaps as products, liquidity marketplaces as investments, or personalised custody advice. It does not claim offers are universally deployed, always private, or always preferable to LNURL. It does not treat a static lno as a reusable payment_hash. Merchant checkout, refunds, and ATM-shaped flows are adjacent protocol territory — not this tip-jar brief.

Educational takeaway: publish an offer → negotiate a fresh invoice over onion messages → pay a unique hash. Sticky entry. One-shot settlement object. Blinded paths for reachability and recipient privacy. Receive-only still means inbound capacity and being online enough to answer.

Related on CryptoDecentral

• Self-custody & wallets pillar
• Privacy pillar
• Network metrics
• Receive-Only Lightning Is Not a Merchant Stack
• Self-Custody Without Verify-Before-Trust Is a Slogan

Further reading (primary)

• BOLT #12 — Offer Encoding / Negotiation Protocol
• Route Blinding proposal
• BOLT #11 — Invoice Protocol for Lightning Payments
• BOLT #0 — Introduction