Offers (BOLT12) aim to replace many awkward invoice flows with reusable, negotiable payment requests delivered over onion messages.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: reusable ask, fresh invoice
Static QR codes, refunds, and recurring flows are painful with single-use BOLT11 strings. Offers are the protocol direction for better UX — but support varies by implementation.
Analogy: BOLT11 is a single-use concert ticket printed on demand. An offer is a box office that can issue fresh tickets when you ask, without a giant static poster that goes stale.
- Payee publishes an offer
- Payer requests an invoice over Lightning messaging
- Payee returns a fresh invoice bound to that request
- Payer pays as usual
Loading diagram…
Done when: You can explain why an offer is not itself the final BOLT11 string.
Step 3 — Contrast + optional lab
Write the BOLT11 vs offers contrast. Check one implementation’s docs (e.g. CLN) for offer support. Optional Polar/CLN create/decode if available.
Common mistakes
- Assuming every wallet can scan offers today
- Mixing offer UX copy with BOLT11 field names in APIs
- Ignoring onion message connectivity requirements
Done when: Lab evidence (contrast + support note + BOLT12 link) is complete.
Next lesson
LNURL — HTTP-based UX still widely deployed alongside offers.