BOLT 11 is the standard for a signed Lightning invoice encoded in Bech32. It carries a payment hash, payee information and payment conditions; it is a request, not proof of successful payment.
Bech32 has a checksum against transcription errors; it is not encryption. An ECDSA signature over secp256k1 protects the invoice content and binds it to the payee’s key, not to a verified person. Unlike Bech32 addresses, BOLT 11 has no 90-character limit. QR codes can use uppercase; mixed case is invalid. [BOLT 11 — Invoice protocol]
The lnbc prefix means mainnet, lntb testnet, lntbs signet and lnbcrt regtest. The amount is in BTC with multiplier m, u, n or p. With p the final digit must be 0 to give whole msat; 1000 msat is one satoshi. A missing amount means the payer supplies it, not a zero payment. [BOLT 11 — Invoice protocol]
Field p carries the payment hash: SHA256 of the payment preimage. Field s carries payment_secret, which the recipient requires in the final part of the routed payment. The secret is neither the preimage nor the wallet seed. Current BOLT 11 requires both fields; reading the secret from the invoice does not itself prove payment. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
An invoice contains exactly one alternative: text d or hash h of an external description. For h, the wallet must verify the supplied description’s SHA256; the hash alone does not explain the purchase. A signature binds content to a key, not the truth of a merchant’s promise. Decoded text should be displayed safely as data. [BOLT 11 — Invoice protocol]
Timestamp plus x determines expiry; without x the default duration is 3600 seconds. Field c is min_final_cltv_expiry_delta for the final HTLC in blocks, not another lifetime in seconds; if absent, at least 18 blocks applies. Invoice expiry does not reverse an already completed payment. [BOLT 11 — Invoice protocol]
Field 9 signals required and optional features. An unknown even bit requires rejection, while an unknown odd bit is ignored; known feature dependencies must be satisfied. Basic MPP is allowed only when basic_mpp is offered. Splitting a payment into parts does not create several independent invoices. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
Field r adds routing hints to reach the recipient; it can expose node keys, channel identifiers and fee parameters. It does not prove current liquidity. Optional f can offer an on-chain address, a different payment method with its own fees and confirmations. The whole invoice is therefore neither a private nor a permanently reusable contact. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
After sending, distinguish pending from completed outcomes. Keep the invoice and matching preimage as settlement evidence, not just a QR screenshot. After losing a response, first check the wallet’s state. A new invoice or another payment method may cause another payment; the format alone provides no universal replay protection. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
For the clearest picture, read this entry together with Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. The reverse links also lead from Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.