BOLT11 Lightning Invoice Format Reference: Prefixes, Tagged Fields and Rules
Every Lightning payment starts with the same object: a BOLT11 invoice. Wallets show it as a QR code; underneath it is a compact, fully specified container of exactly three parts and eleven possible tagged fields. This reference lays the format out field by field — what each tag carries, its length, its default, and the rules that make readers reject an invoice — sourced from the canonical Lightning specification. It extends our Lightning BOLTs reference from the spec index down to the wire format of its most-used document.
Quick answer
A BOLT11 Lightning invoice (the lnbc1... string) is bech32 in three pieces: a human-readable part (network prefix lnbc/lntb/lntbs/lnbcrt + optional amount with an m/u/n/p multiplier — the unit is bitcoin, not satoshis), then a 35-bit timestamp, tagged fields, and a 520-bit compact ECDSA signature whose recovery id lets anyone recover the payee node's identity. This reference details all 11 currently defined tagged fields (p/s/d/n/h/x/c/f/r/9/m), their lengths, their defaults (expiry 3600 s; final CLTV delta 18) and the required/optional rules — including the sharp edge of the p multiplier: the last decimal MUST be 0, or the amount would drop below one millisatoshi.
The two rules that break the most payments: exactly one p AND one s are required (without a valid s the reader MUST fail), and exactly one of d or h. The spec ships 16 valid + 10 invalid test vectors — the validation suite for any serious decoder. As of 2026-07-26.
Download CSV Download JSON REST API →
Human-readable part: prefixes & multipliers
| Prefix | Network |
|---|---|
lnbc | Bitcoin mainnet |
lntb | Bitcoin testnet |
lntbs | Bitcoin signet |
lnbcrt | Bitcoin regtest |
| Multiplier | Factor |
|---|---|
m (milli) | 0.001 |
u (micro) | 0.000001 |
n (nano) | 0.000000001 |
p (pico) | 0.000000000001 — last decimal MUST be 0 |
Data-part structure
1) Timestamp — seconds since 1970, 35 bits big-endian. 2) Tagged fields — zero or more, each: type (5 bits) + data_length (10 bits) + data (data_length × 5 bits; max 639 bytes). 3) Signature — compact secp256k1 ECDSA (64-byte R||S + 1-byte recovery id) over the SHA-256 of the UTF-8 human-readable part concatenated with the data part excluding the signature, zero-padded to a byte boundary.
The 11 tagged fields
| Tag | Name | Length | Meaning | Rule |
|---|---|---|---|---|
p (1) | payment_hash | 52 x 5 bits (fixed) | 256-bit SHA256 payment hash; the preimage of this hash provides proof of payment. | REQUIRED — exactly one |
s (16) | payment_secret | 52 x 5 bits (fixed) | 256-bit secret that prevents forwarding nodes from probing the payment recipient; used as payment_secret in the onion payload. | REQUIRED — exactly one; reader MUST fail the payment without a valid s |
d (13) | description | variable | Short description of the purpose of payment, valid UTF-8. | Exactly one of d or h REQUIRED (both or neither = invalid) |
n (19) | payee node id | 53 x 5 bits (fixed) | 33-byte public key of the payee node. If provided, the reader MUST validate the signature against it (low-S required) instead of performing public-key recovery. | OPTIONAL |
h (23) | description_hash | 52 x 5 bits (fixed) | 256-bit SHA256 of a longer description of the payment purpose, served out-of-band; commits to descriptions over the 639-byte field limit. | Exactly one of d or h REQUIRED |
x (6) | expiry | variable (minimal encoding) | Expiry time in seconds, big-endian. Default 3600 (1 hour) if not specified. | OPTIONAL |
c (24) | min_final_cltv_expiry_delta | variable (minimal encoding) | Minimum CLTV expiry delta for the last HTLC in the route. Default 18 if absent; the reader MUST use at least 18. | OPTIONAL (writer SHOULD include one) |
f (9) | fallback on-chain address | variable, by address version | Fallback address for on-chain payment: a 5-bit version + witness program, or 17 + pubkey hash (P2PKH), or 18 + script hash (P2SH). Readers MUST skip f fields with unknown versions. | OPTIONAL (one or more, most-preferred first) |
r (3) | route hint (private route) | variable; entries of 264+64+32+32+16 bits | One or more ordered entries (pubkey, short_channel_id, fee_base_msat, fee_proportional_millionths, cltv_expiry_delta) giving the forward route from a public node to the destination; multiple r fields allowed. | REQUIRED (at least one) if no public channel is associated with the payee key |
9 (5) | feature bits | variable (minimal encoding) | Big-endian feature vector (BOLT 9) of features supported or required for receiving this payment; follows the it's-ok-to-be-odd rule. Unknown EVEN bits make the reader fail the payment; unknown odd bits are ignored. | OPTIONAL — MUST be omitted entirely if all-zero |
m (27) | metadata | variable (limited by hop payload size) | Additional metadata attached to the payment; the reader MUST send it as payment_metadata in the onion payload. Supports recipients that keep no per-payment state. | OPTIONAL |
Source: the canonical lightning/bolts 11-payment-encoding.md (fetched 2026-07-26). Invoices encode as bech32 (BIP-173) without the 90-character limit; recommended URI scheme: lightning:. Pairs with the Lightning BOLTs reference and the glossary definition. The spec ships 16 valid + 10 invalid test vectors — the validation base for a future in-browser decoder.
The invoice’s 9 field carries BOLT 9 feature bits — see the feature-bits reference for what each one means.
Related products, repair, and setup paths
- how D-Central diagnoses ASIC repairs
- ASIC troubleshooting library
- ASIC manuals and repair guides
- replacement hashboards
- ASIC control boards
- ASIC power supplies
- S19 family replacement hashboard
- C52 replacement control board
- APW12 S19 power supply
- immersion cooling hub
- home immersion cooling guide
- ASIC miners for immersion planning
- ASIC cooling parts
- airflow shroud before immersion
- compare miner specs in the database
- ASIC repair support
Last reviewed July 26, 2026.