Lightning Invoice (BOLT11)

A Lightning invoice in the BOLT11 format is a single bech32-encoded string that packs everything a sender needs to make a Lightning payment. It is the standard payment-request format of the network — the long lnbc... string you scan as a QR code or paste into a wallet. One string, generated by the recipient's node and signed by it, carries the destination, the amount, the cryptographic challenge, and the routing hints; the sender's wallet decodes it and takes care of everything else.

What's inside the string

The string is bech32-encoded, the same checksummed format as native SegWit addresses, so a mistyped or corrupted character is caught before any payment attempt. The human-readable prefix encodes the network (lnbc for mainnet Bitcoin, lntb for testnet) and optionally the amount, using multiplier suffixes — m for milli, u for micro, n for nano, p for pico-bitcoin — which is how an invoice can request amounts down to fractions of a satoshi, settled as millisatoshis inside the network. The data portion carries a timestamp and a series of tagged fields: the payment hash — the SHA-256 of a secret preimage the recipient holds — an expiry (commonly one hour), a description or its hash, the recipient's public key, and a min-final-CLTV value for the last hop. It may also include route hints for reaching recipients whose channels are unannounced: each hint lists a peer's pubkey, short channel ID, fee parameters, and CLTV delta, giving the sender a private on-ramp the public graph cannot show. The whole payload is signed by the recipient's node key, so a wallet can verify who is asking to be paid before a single satoshi moves.

How it drives a payment

The payment hash is the heart of the mechanism. The sender never sees the preimage, only its hash, and the sender's node constructs a chain of HTLCs along a route, every one locked to that same hash. When the recipient claims the final hop by revealing the preimage, the secret cascades back along the path, atomically settling every hop — and handing the sender the preimage as a cryptographic receipt. Large payments may be split across several routes with multi-path payments, all locked to the same invoice. This is why an invoice is single-use by design: once the preimage is public, the payment hash can no longer safely lock funds, and paying the same BOLT11 string twice risks loss. Wallets enforce this, but it is worth understanding rather than merely obeying.

Limits and successors

Single-use is BOLT11's defining constraint. A static donation QR code, a recurring bill, an identity you can print on a business card — none of these fit a format where every request must be freshly generated. BOLT12 offers address this at the protocol level with reusable, signed offers fetched over onion messages, while the Lightning Address convention layers a human-readable, email-style identifier on top of web servers that mint BOLT11 invoices on demand. Both are growing; BOLT11 remains the format virtually every wallet, node, and point-of-sale system speaks today.

Practical notes for the self-hosted

Running your own node means minting your own invoices — no processor, no custodian, no permission. A few habits pay off: set sane expiries for your use case, remember that unannounced channels need route hints or payments will simply fail to find you, and treat preimages as the receipts they are, worth logging for dispute-proof bookkeeping. BOLT11 is one of the most widely implemented parts of the BOLT specification, and decoding one by hand — every field is documented — is a fine first step toward actually understanding what your node signs on your behalf.