Offers: Lightning's Native Experience, Everywhere

Offers is a draft specification (called a "BOLT") for Lightning wallets and nodes, with experimental support already in Core lightning.

We host an HTML copy of the latest text.


BOLT12 Offer

You scan a QR code, your wallet prompts you to pay it, just like BOLT11 invoices today (the QR code labelled BOLT11 Invoice).

But it could send you money, like for an ATM.

And unlike invoices, you can (and should!) reuse them: a static image on your web page, a QR code on your billboard. The BOLT 12 offer can be used by as many people as want to: the BOLT 11 invoice can only be used once, and is insecure if someone else tries to reuse it!

BOLT11 Invoice

How It Works

An "offer" has enough information for you to reach out and fetch a real invoice from the issuer, through the Lightning Network itself, just like it would send a payment: no web server needed. Your wallet then pays the actual invoice (or, if you scan an "invoice_request", your wallet sends an invoice which the vendor pays, as an ATM or refund would use).

This means that offers can be much smaller than invoices, and contain more information (currency, vendor name, quantity limits, blinded paths to reach the vendor).


I am Rusty Russell, lead developer of Core lightning for Blockstream, which was the first implementation of the lightning network, and was the original chair of the Lightning Specification process. I also wrote the BOLT11 specification which defines lightning invoices used today, and so am very familiar with its limitations as the Lightning Network becomes ever more sophisticated.


The draft was first posted September 2020, and revised heavily since. It was first implemented in c-lightning v0.9.3 released in January 2021, but since increased feedback and implementations come on board, it could change again.


Onion messages are still in draft, too, though simple to implement: the current c-lightning implementation opens a direct connection to send onion messages if it needs to (bad for privacy unless you're using Tor!).

There's a REST API to decode offers, request invoices, and decode the invoices at; this includes extensive examples for usage. Obviously using this API exposes your information, but it makes wallet support trivial.


Offers are defined in the draft specification as BOLT12 (vs BOLT11 which defines invoices today); you can review the draft on GitHub

Onion Messages

Using the same onion mechanism we use to send payments, without the actual payment part. You can (and people do!) use fake payments to send messages today, but it's 3x slower and consumes far more resources on each hop.

Blinded Paths

This is supported in both onion messages and payments. It means the sender doesn't know where the message is going, but includes encrypted blobs given in the onion message. This is used for onion message replies, for example. It also allows offers to avoid revealing the node id of the issuer, if they want to.

Schnorr Signatures

BOLT 12 uses Schnorr signatures throughout, which make implementing multisig Lightning nodes transparently possible in future.

Payer proofs

Your wallet creates a "payer key" when it requests an invoice: it can use this to prove to it owns the invoice (even the issuer can't fake this). This is used to claim refunds, for example (and with Blinded Paths you don't need to reveal your node identity to get your money back!).

Merkle Trees

Invoice requests, and invoices themselves are signed as a Merkle tree, which allows you to prove you made a payment, *without* revealing the details you don't want to.

Wire protocol

Offers, invoice requests and invoices are encoded using the exact same protocol as the Lightning Network uses today, just represented using the QR-code friendly bech32 character set.


By using the compatibility schemes already used by the Lightning Network (feature bits, new fields) it's easy to expand for new uses in the future. There are already a few extension proposals!


By using the Lightning Network to send messages, there's no need to run a web server or even deal with that: your lightning node does all the work of serving invoices for offers, and taking the money.


You can see some simple examples on the BOLT12 API Examples page.

Developing Offers

There are various people working on libraries and integration of offers: you can reach us on our Telegram channel.