LearnBitcoin

Glossary

BOLT 11

A Lightning Network invoice format (commonly starting lnbc...) that encodes payment data like amount and destination.

BOLT 11 is the specification for Lightning invoices - the encoded payment requests that begin with lnbc (mainnet) or lntb (testnet). It's one of the BOLT specs that define how Lightning implementations interoperate.

A BOLT-11 invoice encodes everything a payer needs to complete a payment:

  • Amount (optional - the payer can specify if the invoice doesn't).
  • Payment hash - hash of the secret preimage that, when revealed, completes the payment.
  • Payment secret - a random value that keeps forwarding nodes from probing the recipient.
  • Destination node public key - written out, or recovered from the signature.
  • Routing hints for nodes that aren't well-connected to the public graph (useful for mobile wallets).
  • Expiry - 1 hour if the invoice does not say. Node software often sets a longer one when it creates the invoice, such as 24 hours (LND) or a week (Core Lightning).
  • Description / memo - a short note, or a hash of a longer description. Every invoice must carry one or the other.
  • A signature from the recipient's node, proving it created the invoice.

The whole thing is encoded with bech32, the format BIP 173 defined for native SegWit addresses, without that format's 90-character length limit. The result is a single string, typically a few hundred characters long, that fits in a QR code and can be copy-pasted, scanned, or NFC-tapped.

BOLT-11 invoices are single-use by design. Once a payment settles, the preimage is no longer secret, because the payer and every node on the route have seen it. If a second payment to the same invoice passes through any of those nodes, that node could keep it instead of forwarding it. To take repeated payments at one fixed handle, you need something that hands out a fresh invoice each time, such as BOLT-12 offers (the modern successor) or an invoice-per-payment service.

BOLT-11 was added to the Lightning spec in June 2017 and became Lightning's payment-request lingua franca. BOLT-12 offers, merged into the spec in September 2024, fix several of its limitations. See Lightning invoice for where support for offers stood as of October 2026.

Key takeaways

  • Encodes LN payments in a structured invoice format
  • Specifies amount, receiver's node, and optional data
  • Provides a standard, user-friendly way to request Lightning payments

Related chapters

Corrected

  • Was: The entry called the description optional, described an encoded invoice as a relatively short string, and said paying an invoice a second time would either fail or be a fraud signal.

    Now: Every invoice must carry a note or a hash of a longer description, and invoices typically run to a few hundred characters, past the 90-character limit of bech32 addresses. Once a payment settles, its preimage is no longer secret, so a node on the original route could keep a second payment to the same invoice that passes through it. Details

Sources (7)

External references (1)

Related terms (17)

Published . Revised . One correction logged for this page.

Edit this page on GitHub