Invoice Encoding

What Is Invoice Encoding?

Invoice encoding is the method used to represent a Lightning Network payment request as a compact, self-contained string. When someone wants to receive a Lightning payment, their node generates an encoded invoice that contains everything the sender needs: how much to pay, where to route the payment, what cryptographic hash to lock the funds to, and when the request expires.

The encoding format defined in the BOLT specification (specifically BOLT 11) uses the same Bech32 character set as Bitcoin SegWit addresses but carries far more data. While a SegWit address is 42 to 62 characters long, a Lightning invoice typically spans 200 to 500 characters or more, depending on how many routing hints it includes.

How It Works

A BOLT 11 invoice is a single Bech32-encoded string divided into four parts: a human-readable prefix, a separator, a data section, and a checksum.

Human-Readable Prefix

The prefix always starts with ln followed by a currency code and an optional amount:

• lnbc: Bitcoin mainnet
• lntb: Bitcoin testnet
• lntbs: Bitcoin signet
• lnbcrt: Bitcoin regtest

The amount is encoded as a decimal integer followed by a multiplier suffix: m for milli (0.001), u for micro (0.000001), n for nano (0.000000001), or p for pico (0.000000000001). For example, lnbc2500u represents a request for 2,500 microsatoshis worth of bitcoin (250,000 satoshis). If no amount is specified, the sender chooses how much to pay.

Separator

The character 1 separates the human-readable prefix from the data part, following the same convention as on-chain Bitcoin addresses.

Data Section

The data section contains three components:

1. A 35-bit timestamp recording when the invoice was created (seconds since Unix epoch)
2. A series of tagged fields carrying the payment details (described below)
3. A 65-byte signature: a 64-byte secp256k1 signature (R and S values) plus a 1-byte recovery ID, generated deterministically using RFC 6979

Tagged Fields

Each tagged field follows a type-length-value structure: a 5-bit type tag, a 10-bit data length (in 5-bit groups), and the data itself. The key fields include:

Routing Hint Structure

Each routing hint entry is exactly 51 bytes and describes one hop of a private route to the receiver:

Routing hint entry (408 bits / 51 bytes):
  pubkey:                     33 bytes  (node ID of channel peer)
  short_channel_id:            8 bytes  (channel identifier)
  fee_base_msat:               4 bytes  (base fee in millisatoshis)
  fee_proportional_millionths: 4 bytes  (proportional fee in ppm)
  cltv_expiry_delta:           2 bytes  (CLTV expiry delta)

Multiple entries within a single r field form an ordered route from a public node to the destination. Multiple r fields provide alternative routes. Invoices with many routing hints grow substantially in length, which directly affects QR code size.

Example Invoice Breakdown

lnbc2500u1pjq2ywzpp5...

Prefix:    lnbc       (Bitcoin mainnet)
Amount:    2500u      (250,000 satoshis)
Separator: 1
Timestamp: pjq2ywz   (encoded creation time)
Tags:      pp5...     (payment hash, description, etc.)
Signature: last 104 characters
Checksum:  last 6 characters

Bech32 and Error Detection

Lightning invoices use Bech32 encoding (defined in BIP-173) with a carefully chosen 32-character alphabet: qpzry9x8gf2tvdw0s3jn54khce6mua7l. This character set excludes visually ambiguous characters like 0/O, 1/l/I, and b/6, reducing transcription errors when invoices are communicated manually.

The 6-character BCH checksum guarantees detection of any error affecting up to 4 characters, with less than a one-in-a-billion chance of missing errors affecting more characters. This is critical for payment requests where a single wrong character could send funds to the wrong destination or make the invoice unpayable.

Note that BOLT 11 uses the original Bech32 (BIP-173), not Bech32m (BIP-350). Bech32m was introduced to fix a length-extension weakness in original Bech32 and is used for Taproot on-chain addresses, but Lightning invoices retain the original encoding.

QR Code Representation

Lightning invoices are frequently shared as QR codes, especially at point-of-sale terminals and in mobile wallets. The BOLT 11 specification recommends converting invoice strings to uppercase when generating QR codes.

The reason is efficiency: QR codes support an alphanumeric mode that encodes two characters into 11 bits (5.5 bits per character), compared to byte mode at 8 bits per character. Since Bech32 is case-insensitive, uppercasing loses no information but reduces QR code density by roughly 45%. The result is fewer modules (black and white squares), making the code easier to scan with lower-quality cameras.

Size remains a practical concern. A minimal invoice with no routing hints might be 250 characters, producing a manageable QR code. But an invoice with four or five routing hints can exceed 500 characters, creating dense QR codes that struggle on older devices. This size limitation is one reason BOLT 12 offers were designed to be dramatically shorter: a typical offer is 50 to 100 characters, making it practical to print on business cards or display as a static QR code.

Comparison with On-Chain Address Formats

Both Lightning invoices and on-chain Bitcoin addresses use Bech32 encoding, but they serve fundamentally different purposes:

On-chain addresses are lightweight pointers to a script condition. Lightning invoices are self-contained payment instructions with cryptographic authentication. This richness enables trustless payment routing across multiple hops but comes at the cost of length and single-use semantics.

Limitations and the Path to BOLT 12

Several design constraints in BOLT 11 invoice encoding drove the development of BOLT 12 offers:

• Single-use: each invoice contains a unique payment hash and can only be paid once. The preimage revealed during payment makes reuse insecure, so merchants must generate a new invoice per transaction.
• Receiver must be online: the recipient's node must be running to create an invoice. If the node goes offline, no invoices can be generated and no payments can be received.
• Privacy exposure: the invoice reveals the recipient's node public key (either in the n field or recoverable from the signature), allowing anyone who sees the invoice to identify the receiving node.
• No native recurrence: there is no built-in mechanism for subscription payments or recurring billing within BOLT 11.
• Out-of-band exchange: invoices must be communicated outside the Lightning Network itself (via web, messaging, or QR codes), adding friction to the payment flow.

BOLT 12 addresses these issues with a three-step flow: offer, invoice request, and invoice. Offers are static and reusable (prefixed lno1), support blinded paths for recipient privacy, and can be exchanged directly through the Lightning Network via onion messages. As of 2026, BOLT 12 has been merged into the Lightning specification and is supported natively in Core Lightning and Eclair, with LDK offering library-level support. LND support remains experimental behind a feature flag.

Use Cases

Point-of-Sale Payments

Merchants generate a BOLT 11 invoice for each transaction and display it as a QR code. The customer scans with a mobile wallet, verifies the amount and description, and pays. The invoice's embedded amount prevents overpayment, and the expiry field ensures stale requests are automatically rejected.

Programmatic Billing

APIs and services generate invoices dynamically for metered usage, per-request billing, or one-time purchases. The invoice's self-contained format means clients need no prior relationship with the server: the invoice string contains all information needed to complete payment. Protocols like LNURL build on this by automating invoice generation behind HTTP endpoints.

Cross-Layer Swaps

Submarine swaps and similar protocols rely on the payment hash embedded in the invoice to atomically link a Lightning payment to an on-chain transaction. The hash serves as a shared secret that coordinates settlement across layers, enabling trustless movement of funds between the Bitcoin base layer and Lightning.

Risks and Considerations

Invoice Expiry and Failed Payments

Invoices expire by default after one hour. If a sender attempts to pay an expired invoice, the payment fails. Applications that generate invoices well in advance of payment (such as email-based billing) must account for this constraint by either extending the expiry or regenerating invoices on demand.

Invoice Size and Scanning Reliability

Invoices with many routing hints can exceed 500 characters, producing large QR codes. On older devices or in low-light conditions, dense QR codes may fail to scan. Wallet developers can mitigate this by limiting the number of routing hints included or by falling back to NFC or clipboard-based sharing.

Privacy Trade-offs

Every BOLT 11 invoice reveals the recipient's node public key, which is linkable to an IP address through the Lightning gossip protocol. For privacy-sensitive users, this is a significant concern. BOLT 12 offers with blinded paths provide a stronger privacy model by hiding the recipient's identity from the sender.

Single-Use Constraint

Reusing a BOLT 11 invoice is insecure: once the preimage is revealed to settle the first payment, anyone who knows it can claim subsequent payments locked to the same hash. Applications must never present the same invoice to multiple payers. For scenarios requiring a static payment identifier, alternatives like LNURL, keysend, or BOLT 12 offers are appropriate.

For a deeper comparison of BOLT 11 and BOLT 12 invoice formats, see the research article on Lightning invoices: BOLT 11 vs. BOLT 12.

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.