Lightning Invoice

What Is a Lightning Invoice?

A Lightning invoice is a payment request that contains all the information a sender needs to route a payment through the Lightning Network. Think of it as a QR-scannable bill: the recipient generates the invoice, shares it with the payer, and the payer's wallet uses the embedded data to construct and send the payment.

Invoices solve a fundamental coordination problem. On the base Bitcoin layer, you can send to an address without the recipient doing anything. On Lightning, payments travel through a chain of HTLCs locked to a specific hash, so the recipient must first generate that hash and communicate it to the sender. The invoice is the standardized format for this communication, defined in the BOLT-11 specification.

How It Works

Every Lightning invoice is a bech32-encoded string that packs a human-readable prefix, a data payload, and a cryptographic signature into a compact format. When a wallet scans or pastes an invoice, it decodes these three parts and uses them to construct the payment.

Anatomy of a BOLT-11 Invoice

A raw invoice looks like a long string starting with lnbc (mainnet) or lntb (testnet). It breaks down into three sections:

1. Human-readable prefix: indicates the network and amount. For example, lnbc2500u means a mainnet invoice for 2,500 microsatoshis.
2. Data part: a series of tagged fields containing the payment hash, expiry, description, route hints, and other metadata, all encoded in base32.
3. Signature: a 65-byte secp256k1 signature over the entire invoice, proving it was created by the owner of the destination node's public key.

Invoice Fields

The data part consists of tagged fields, each identified by a single character. The most important fields are:

Encoding and Decoding

BOLT-11 invoices use bech32 encoding, the same scheme used for native SegWit Bitcoin addresses. Bech32 provides built-in error detection via a checksum and uses a character set that avoids ambiguous characters (no "0" vs "O" confusion). You can decode any invoice using standard Lightning tooling:

# Decode a BOLT-11 invoice using lncli
lncli decodepayreq lnbc2500u1pvm...

# Output:
{
  "destination": "03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221e",
  "payment_hash": "0001020304050607...",
  "num_satoshis": "250",
  "timestamp": "1700000000",
  "expiry": "3600",
  "description": "Coffee at Lightning Cafe",
  "cltv_expiry": "18",
  "route_hints": [...],
  "payment_addr": "abcdef1234567890...",
  "features": { "14": { "name": "payment-addr", "is_required": true } }
}

The Payment Flow

Once a sender decodes the invoice, the payment follows a precise sequence:

1. The receiver generates a random 32-byte preimage and computes its SHA-256 hash (the payment hash)
2. The receiver encodes the payment hash, amount, and metadata into a BOLT-11 invoice
3. The sender decodes the invoice and finds a route to the destination node
4. The sender constructs an onion-routed HTLC locked to the payment hash
5. Each hop forwards the HTLC to the next node along the route
6. The receiver reveals the preimage to claim the final HTLC
7. The preimage propagates back through each hop, settling the entire chain of HTLCs

This entire process typically completes in under a second. If the payment fails at any hop, the HTLCs time out and the sender's funds are returned.

Use Cases

Point-of-Sale Payments

The most common use of Lightning invoices is merchant payments. A merchant generates an invoice for the purchase amount, displays it as a QR code, and the customer scans and pays. The invoice's description field typically includes order details, and the short expiry window prevents stale payment requests from lingering.

Withdrawals and Payouts

Exchanges and services use Lightning invoices for user withdrawals. The user generates an invoice from their wallet, pastes it into the withdrawal form, and the service pays it. This is the reverse of merchant payments: the recipient creates the invoice and shares it with the payer.

Conditional and Held Payments

Hodl invoices extend the standard invoice pattern by delaying settlement. The receiver withholds the preimage until conditions are met, enabling escrow-like functionality. This is useful for marketplace payments, atomic swaps, and any scenario requiring conditional release of funds.

Multi-Path Payments

When a single channel lacks sufficient capacity, multi-path payments split the invoice amount across multiple routes. The payment secret field in the invoice ensures that partial payments can only be claimed together, preventing intermediary nodes from stealing individual parts. Atomic multipath payments guarantee that either all parts settle or none do.

Risks and Considerations

Invoice Reuse

BOLT-11 invoices must never be reused. Once a payment settles, the preimage is revealed to every routing node along the payment path. If the same invoice (same payment hash) is paid again, any of those routing nodes can intercept the second payment by submitting the preimage they already know. This makes the second payment insecure.

This is not just a theoretical risk: it is a fundamental property of the hash-based payment scheme. Wallets and services must generate a fresh invoice (with a new preimage and hash) for every payment. The single-use nature of invoices is one of the primary motivations behind BOLT-12 offers, which provide reusable payment endpoints without reusing payment hashes.

Expiry and Staleness

Invoices expire after a set period (default: one hour). If a sender attempts to pay an expired invoice, their wallet should reject it. However, if the sender initiates payment just before expiry and the route takes time to resolve, edge cases can arise where the receiver has already discarded the preimage. Short expiry times reduce this risk but require timely coordination between parties.

Privacy Limitations

A standard BOLT-11 invoice reveals the recipient's node public key to the sender. This links payments to a specific node identity. For users who need stronger privacy, blinded paths (used in BOLT-12) hide the recipient's node behind multiple hops, preventing the sender from learning the destination.

Online Requirement

The receiver must be online to generate an invoice and to settle the incoming HTLC. This makes Lightning invoices unsuitable for asynchronous "leave a tip" scenarios where the recipient might be offline. Solutions include static payment codes, keysend (which requires no invoice at all), and BOLT-12 offers with onion-message-based invoice delivery.

Invoice-less Payments: Keysend

Keysend is an alternative payment method that bypasses invoices entirely. Instead of the receiver generating a preimage, the sender creates one, encrypts it in the onion payload, and sends the payment directly to the destination node. The receiver decrypts the onion to discover the preimage and uses it to claim the HTLC.

Keysend enables spontaneous payments without prior coordination: you only need the recipient's node public key. However, it sacrifices proof-of-payment (the sender already knows the preimage) and requires the recipient to be online to accept the payment.

The Evolution: BOLT-12 Offers

BOLT-12 represents the next generation of Lightning payment requests, addressing many of BOLT-11's limitations:

• Reusable payment endpoints: a single offer can generate unlimited invoices, eliminating the single-use restriction
• No recipient node exposure: offers use blinded paths to hide the recipient's identity
• Asynchronous flow: the sender and receiver do not need to be online simultaneously during the offer exchange phase
• Refund support: BOLT-12 natively supports refund flows, which BOLT-11 has no mechanism for
• Currency flexibility: offers can specify amounts in fiat currencies, with the actual satoshi amount determined at invoice-creation time

While BOLT-11 invoices remain the dominant standard today, BOLT-12 adoption is growing as implementations like CLN and LDK add support. For a deeper exploration of how Lightning payment infrastructure is evolving, see the Lightning Network liquidity explained research article.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.