Lightning Invoices: BOLT 11, BOLT 12, and Beyond

Every Lightning Network payment begins with an invoice. When you scan a QR code to pay a friend or settle a tab at a merchant, the string you are reading is a Lightning invoice: a cryptographically signed request for a specific amount to be delivered over a specific route within a specific time window. The encoding format, field structure, and limitations of these invoices shape the entire payment experience for senders and receivers alike.

The dominant standard today is BOLT 11, defined in the original Lightning specification. But BOLT 11 was designed for a simpler era. Its single-use invoices expire, its QR codes are large, and the receiver must be online to generate them. A newer standard, BOLT 12, introduces reusable payment codes called offers, along with receiver privacy via blinded paths. Meanwhile, keysend allows spontaneous payments with no invoice at all.

This article decodes the BOLT 11 format field by field, walks through its limitations, explains how BOLT 12 offers solve them, and covers keysend and the emerging standards that are pushing Lightning invoices toward obsolescence.

How Lightning Invoices Work

A Lightning invoice is fundamentally a request-to-pay. The receiver generates a random 32-byte secret called the preimage, computes its SHA-256 hash (the payment hash), and packages the hash along with payment metadata into a signed, encoded string. The sender uses this string to construct a payment route and lock funds in a chain of HTLCs conditioned on the payment hash.

When the payment reaches the receiver, they reveal the preimage to claim the funds. The preimage propagates backward through every routing node, with each hop using it to unlock the HTLC from the upstream node. This atomic settlement mechanism ensures that either every node along the route gets paid or none of them do.

Why the preimage matters: In a standard BOLT 11 payment, only the receiver knows the preimage before settlement. This gives the sender a cryptographic proof of payment: possession of the preimage proves the receiver acknowledged and accepted the payment. This property breaks down with keysend, where the sender generates the preimage themselves.

BOLT 11 Invoice Format Decoded

A BOLT 11 invoice is a single bech32-encoded string with three sections: a human-readable prefix, a data payload of tagged fields, and a trailing signature. The encoding uses the original bech32 format from BIP 173 (not bech32m) and includes a 6-character checksum.

Human-Readable Prefix

The prefix starts with ln followed by a BIP 173 currency code: lnbc for Bitcoin mainnet, lntb for testnet, lnbcrt for regtest. An optional amount follows, expressed in the currency's base unit (bitcoin, not satoshis), with a multiplier suffix:

• m (milli): multiply by 0.001
• u (micro): multiply by 0.000001
• n (nano): multiply by 0.000000001
• p (pico): multiply by 0.000000000001

For example, lnbc2500u means 2,500 micro-bitcoin, which equals 250,000 satoshis. Omitting the amount creates a "zero-amount" invoice where the sender chooses how much to pay.

Tagged Fields

The data section begins with a 35-bit big-endian Unix timestamp, followed by a variable number of tagged fields. Each field consists of a 5-bit type tag, a 10-bit data length, and the field data itself. The maximum data length per field is 1,023 groups of 5 bits (639 bytes).

Signature and Encoding

The invoice is signed with ECDSA over secp256k1 using the receiver's node private key. The signature covers the SHA-256 hash of the human-readable prefix (as UTF-8 bytes) concatenated with the data part (excluding the signature itself). The result is a 65-byte value: a 64-byte compact R||S signature plus a 1-byte recovery ID (0 through 3), which allows the sender to recover the public key without needing the n field.

The BOLT 11 specification recommends uppercase encoding for QR codes because bech32 uses only alphanumeric characters, and QR alphanumeric mode is more compact with uppercase letters. This reduces QR code density, but invoices with multiple route hints can still produce large, hard-to-scan codes.

Limitations of BOLT 11 Invoices

BOLT 11 has served the Lightning Network well since its introduction, but several design constraints create friction as the network scales.

Single-Use by Design

Each invoice contains a unique payment hash. Once paid, the preimage is revealed to every routing node along the path. If the same invoice were paid a second time, any node that remembers the preimage could settle the HTLC and steal the funds rather than forwarding. This makes BOLT 11 invoices strictly single-use: merchants must generate a fresh invoice for every customer, every checkout, every payment request.

Expiration Creates UX Friction

The default expiry of one hour forces a trade-off. Short expiry windows mean invoices go stale before the payer acts. Long expiry windows mean the receiver must maintain channel state and reserve inbound liquidity for potentially abandoned invoices. Neither option works well for asynchronous commerce like tip jars, donation pages, or offline merchants.

Receiver Must Be Online

The receiver must be online at two points: first to generate the invoice (creating the preimage, computing the hash, signing and encoding the string), and again to settle the incoming HTLC by revealing the preimage. A mobile wallet user who closes their app cannot receive payments until they reopen it, and they cannot even share an invoice without first connecting to their node.

Privacy Limitations

BOLT 11 invoices expose the receiver's node public key, either directly in the n field or recoverable from the signature. Anyone who sees the invoice can identify exactly which node is receiving the payment. Route hints, while necessary for nodes with only private channels, further leak information about the receiver's channel topology. The privacy implications extend to payment correlation: the same payment hash appears at every hop, making multi-hop payments linkable by any two colluding routing nodes.

No Refund Mechanism

BOLT 11 defines a request-to-pay format only. There is no protocol-level mechanism for the receiver to return funds. Refunds require a completely separate out-of-band process where the original payer generates their own invoice and communicates it back to the merchant.

BOLT 12 Offers: Reusable Payment Codes

BOLT 12 was officially merged into the Lightning specification in September 2024, the first new BOLT addition since 2017. It introduces a fundamentally different model: instead of generating a new invoice for every payment, the receiver publishes a static, reusable offer. The offer contains enough information for any payer to request a fresh invoice directly from the receiver's node, all over the Lightning Network itself.

For a deeper look at BOLT 12 capabilities and how they compare to LNURL, see our dedicated BOLT 12 offers explainer.

The Offer-Request-Invoice Flow

BOLT 12 replaces the single-step "generate invoice, share out-of-band" model with a three-step protocol that runs entirely over Lightning's onion message layer:

1. The receiver creates an offer (prefix: lno1) containing a description, optional amount, optional currency (supporting ISO 4217 codes like USD), blinded paths to themselves, and an expiry. Offers are unsigned and compact enough for a static QR code.
2. The payer scans the offer and their node constructs an invoice_request (prefix: lnr1) containing the payer's transient public key and the desired amount. This request is delivered to the receiver via an onion message routed through the blinded path.
3. The receiver's node generates a fresh invoice (prefix: lni1) with a unique payment hash, blinded payment paths, and a BIP-340 Schnorr signature. The payer then pays this invoice as a normal Lightning payment.

The critical difference: no web server, no HTTP endpoint, no external infrastructure. The entire negotiation happens natively over the Lightning Network using onion messages defined in BOLT 4. This contrasts with LNURL, which requires an HTTPS server to coordinate invoice generation.

Blinded Paths for Receiver Privacy

Blinded paths (route blinding, defined in BOLT 4) allow the receiver to construct a partial route from a publicly known "introduction node" to themselves, then cryptographically blind all intermediate nodes along that path. The sender only learns the introduction node's identity and forwards the payment there. They never discover the receiver's node ID, channel structure, or network position.

In practice, 2 to 3 blinded hops provide strong privacy while keeping failure rates manageable. The receiver specifies all relay parameters (fees, CLTV deltas, feature requirements) for the blinded segment, preventing fingerprinting of the blinded nodes. This is a major improvement over BOLT 11, where the receiver's node ID is always exposed. For more on how onion routing protects Lightning privacy, see our dedicated deep dive.

BOLT 11 vs BOLT 12: Side-by-Side Comparison

BOLT 12 is not a replacement for BOLT 11: Both standards will coexist for years. BOLT 11 remains the universal baseline supported by every Lightning wallet and service. BOLT 12 is additive: it covers use cases (reusable codes, privacy, refunds, subscriptions) that BOLT 11 cannot address. Wallets adopting BOLT 12 still need BOLT 11 support for backward compatibility.

BOLT 12 Implementation Status

BOLT 12 support varies across the four major Lightning implementations. The specification was merged in September 2024, and adoption has accelerated through 2025 and into 2026.

On the wallet and service side, Strike, Phoenix, CoinOS, and Boltz all support BOLT 12 offers. Ocean Mining allows miners to submit BOLT 12 offers for payout. Adoption is accelerating, though BOLT 11 remains the universal fallback.

Keysend: Invoice-Less Spontaneous Payments

Keysend (defined in bLIP-0003) reverses the standard payment flow. Instead of the receiver generating a preimage and sharing its hash via an invoice, the sender generates the preimage and sends it encrypted inside the onion payload of the final hop.

How Keysend Works

1. The sender generates a random, cryptographically secure 32-byte preimage.
2. The sender computes payment_hash = SHA256(preimage).
3. The sender constructs a payment route to the recipient's public key (which must be known beforehand).
4. The preimage is included as a TLV record with type 5482373484 in the final hop's onion payload, encrypted so intermediate routing nodes cannot read it.
5. The recipient decrypts the final hop, extracts the preimage, verifies it matches the payment hash, and settles the HTLC.

Nodes advertise keysend support via feature bits 54 (required) or 55 (optional). Keysend payments can also carry custom data in additional TLV fields: podcasting 2.0 apps use TLV type 34349334 to attach text messages and value-for-value metadata.

Keysend Limitations

The most significant limitation is the loss of proof-of-payment. In a standard BOLT 11 flow, only the receiver knows the preimage before settlement, making preimage possession a cryptographic receipt. With keysend, the sender generates the preimage, so it cannot serve as proof that the receiver acknowledged the payment.

Keysend also provides no way for the receiver to specify a preferred min_final_cltv_expiry delta or communicate any metadata back to the sender. The bLIP-0003 specification notes that keysend is anticipated to be deprecated in favor of BOLT 12 offers, which solve the same "pay-without-prior-communication" use case with better properties.

Beyond Invoices: Emerging Standards

The Lightning ecosystem continues to evolve beyond BOLT 11 and BOLT 12. Several emerging standards address remaining gaps in the payment experience.

Async Payments and Static Invoices

One of BOLT 11's sharpest limitations is the online requirement for receivers. BOLT 12 partially solves this (the offer is static), but the receiver must still be online to respond to the invoice_request and settle the HTLC. Async payment proposals (PR #1149) would allow senders to pay a static BOLT 12 invoice even when the receiver is offline, with the payment held by the network until the receiver comes back online. LDK has added support for paying static BOLT 12 invoices to enable this workflow.

BIP 353: Human-Readable Payment Addresses

BIP 353 defines DNS-based resolution of human-readable names in the format user@domain into bitcoin: URIs containing BOLT 12 offers. The payment information is stored as TXT records at user.user._bitcoin-payment.domain with DNSSEC validation. This is designed to extend or replace the Lightning Address scheme (which relies on HTTPS servers and inherits their trust assumptions). Combined with BOLT 12, BIP 353 would give Lightning something close to email-style payment addresses that work without any web server infrastructure.

PTLCs: Fixing Payment Correlation

Even with BOLT 12's privacy improvements, a fundamental weakness persists: the same payment hash appears at every hop in the route. Two colluding routing nodes can correlate payments by matching hashes. Point Time-Locked Contracts (PTLCs) replace hash-based locks with Schnorr signature-based adaptor signatures, giving each hop a unique lock. This eliminates payment correlation at the protocol level, a critical improvement for Lightning privacy.

Persistent Addresses: How Spark Eliminates Invoice Friction

The invoice model, whether BOLT 11 or BOLT 12, introduces inherent complexity: someone must generate an invoice, someone must scan or paste it, and the invoice must not have expired. For users accustomed to traditional payment apps where you simply send money to an address or username, this workflow feels foreign.

Spark takes a different approach. On Spark, every user has a persistent address that never expires and can receive payments repeatedly without any pre-communication between sender and receiver. There is no invoice to generate, no QR code that goes stale after an hour, and no requirement for the receiver to be online at the moment of payment. Spark Service Providers can hold incoming payments conditionally until the recipient comes online, solving the async payment problem without protocol-level changes to the Lightning specification.

Spark also maintains full compatibility with Lightning. Users can pay BOLT 11 invoices from their Spark balance and receive Lightning payments to their Spark address via atomic swaps through Spark Service Providers. The result is a bridge between Lightning's vast network reach and Spark's simpler payment UX. For details on Lightning channel management and why Spark's channel-free design reduces operational complexity, see our channel management guide.

No channels, no invoices, no expiration: Spark addresses work like account numbers. Send to the same address indefinitely, with no pre-communication, no online requirement, and no expiration. For developers exploring Lightning liquidity challenges, this is a meaningful simplification.

Developers building on Spark can integrate Bitcoin and stablecoin payments using the Spark SDK, which abstracts away Lightning invoice management, channel liquidity, and HODL invoice complexity. For end users, wallets like General Bread demonstrate how Spark-powered payments work in practice: scan, send, done. For more on the routing complexity that Spark sidesteps, see our routing deep dive.

Conclusion

Lightning invoices have evolved substantially from BOLT 11's original single-use, expiring payment requests. BOLT 12 offers bring reusability, receiver privacy, native negotiation, and refund support. Keysend enables spontaneous payments without any prior invoice exchange. Emerging standards like BIP 353 and async payments continue to close the remaining UX gaps.

Yet the invoice model itself introduces complexity that many users and developers find unnecessary. The direction of the ecosystem is clear: toward persistent identifiers, reusable codes, and payment experiences that feel as simple as sending a message. Whether through BOLT 12 offers, BIP 353 payment addresses, or Spark's persistent addresses, the era of manually managing expiring invoices is drawing to a close.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.