How BOLT12 Can Enhance the Lightning User Experience

The Lightning Network aims to make paying with Bitcoin easy. So far, the user experience is often suboptimal—but BOLT12 promises to change that by replacing “Invoices” with “Offers.” It sounds technical, but in practice, it’s impressive—and already live in the first wallets.

When Bitcoiners talk about “BOLT,” they mean the protocol standards for the Lightning Network, spelled out as the “Basis of Lightning Technology“. Similar to BIPs (Bitcoin Improvement Proposals) for Bitcoin, the BOLTs define technical standards that guide the various Lightning implementations. One of the most promising standards right now is BOLT12.

To understand why, it helps to know that Lightning invoices are currently created according to BOLT11. If you want to receive money with Lightning, you enter the amount and generate a payment request — called an invoice — which is usually displayed as a QR code. Such an invoice created via BOLT11 contains the recipient node’s public key, a specific amount in satoshis, and a secret that’s inside every Lightning payment. One of the main issues with BOLT11 is that these invoices are single-use—even if the amount field is left blank.

BOLT12 changes this. The standard replaces the invoice with a so called  „offer“, which developers sometimes refer to as a „meta-invoice.“ It’s much more flexible: you can reuse it, use it to pay or to get paid. BOLT12 is similar to a Bitcoin address—only better—and, in practice, like LNURL (a standard for Lightning payments via web links), except it’s native to the Lightning Network. It doesn’t require a web server, TLS certificates, or any third party.

Thanks to this, BOLT12 significantly enhances the user experience in many cases. You no longer need to generate a new invoice for every transaction—instead, you can reuse a single code over and over, for example when collecting donations. On top of that, BOLT12 expands the range of possible payment modes:

• You can pay using a code, similar to a direct debit. For instance, after you deposited fiat notes, a Bitcoin ATM can display a QR code that users scan to withdraw bitcoins.
• Such debits can also be recurring—ideal for subscriptions, almost like a standing order.
• Because BOLT12 codes are bidirectional, you can also send money back, for example if a product wasn’t delivered, without first requesting an invoice.

Beyond that, BOLT12 comes with some subtle advantages:

• It supports “blind routing,” which allows you to receive money without revealing your node’s public key. This enhances privacy and removes the need to hide your home node via the Tor network.
• BOLT12 can support email-like “payment identifiers” as described in BIP353, all without requiring a web server. This could be the long-awaited breakthrough that enables human-readable addresses without sacrificing privacy or depending on third parties.

In short, BOLT12 delivers many of LNURL’s greatest features, without inheriting its main drawbacks—especially the dependence on a web server.

However, whether BOLT12 will actually replace LNURL remains to be seen. As with much in the Bitcoin and Lightning worlds, development and adoption move slowly. BOLT12 was first proposed in 2020 and has only recently reached production readiness. So far, only two wallets have implemented BOLT12: the highly recommended Phoenix as a “reusable QR code,” and the online wallet Coinos. Both currently only use some of the features that BOLT12 has to offer.

The potential for BOLT12 to make Lightning payments simpler, more private, and richer in features is huge and far from exhausted. However, despite all the excitement, one should not overlook the fact that what might be Lightning’s biggest challenge remains unsolved, even with BOLT12: both parties must be online at the same time for a payment to go through. This is still a hurdle Lightning carries with it.