BOLT11

Overview

BOLT11 is the Lightning Network's invoice ("payment request") format — a bech32-encoded string, conventionally prefixed lnbc..., that encodes everything a payer needs to settle a Lightning payment: amount, payment hash, payee, expiry, routing hints and a recoverable signature.[1] "BOLT" stands for Basis of Lightning Technology, the family of Lightning specifications maintained in the lightning/bolts repository; BOLT #11 is the payment-encoding document.[1] Because a BOLT11 string is compact and bech32-checksummed, it is "QR-code-ready" and is routinely rendered as a qr-code or embedded in a bip-21 lightning= parameter for scan-to-pay.[1][2]

History

BOLT11 is document #11 ("Invoice Protocol for Lightning Payments") of the Lightning BOLT specification set, maintained in the lightning/bolts GitHub repository (~2.2k stars, active 2026).[1] It reuses Bitcoin's bech32 encoding (BIP-173) both for its checksum and for the currency-prefix scheme in its human-readable part.[1][3] The specification has evolved in place — for example feature-bit handling has been revised over time — and the payment-encoding document remains the reference for invoice construction.[1]

Technical specification

A BOLT11 invoice is bech32-encoded and splits into a human-readable part (HRP), a data part, and a signature.[1]

Human-readable part (HRP):[1][3]

• Prefix: ln + a BIP-173 currency code — lnbc (Bitcoin mainnet), lntb (testnet), lntbs (signet), lnbcrt (regtest).
• Amount (optional): a numeric value followed by an optional multiplier letter — m = milli (10⁻³), u = micro (10⁻⁶), n = nano (10⁻⁹), p = pico (10⁻¹²) BTC. Example: lnbc2500u = 2500 micro-bitcoin on mainnet.

Data part (after the bech32 separator 1):[1]

• Timestamp: 35-bit value, seconds since the Unix epoch.
• Tagged fields: each is a 5-bit type, a 10-bit data length, then the data.
• Signature: 520 bits — a 64-byte recoverable ECDSA signature (R‖S) plus a 1-byte recovery id, over the whole invoice, letting the payer recover the payee's node public key.

Key tagged fields:[1]

Code	Field	Notes
p	payment hash	required; 256-bit SHA256
s	payment secret	required; binds the payment, prevents probing
d	description	UTF-8 text
h	description hash	hash of a long description
x	expiry	seconds; default 3600
n	payee node id	33-byte public key
f	fallback on-chain address	optional on-chain payment option
r	routing information	private-channel hop hints

Example invoice (2500 µBTC):[1]

lnbc2500u1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpu9qrsgquk0rl77nj30yxdy8j9vdx85fkpmdla2087ne0xh8nhedh8w27kyke0lp53ut353s06fv3qfegext0eh0ymjpf39tuven09sam30g4vgpfna3rh

Use cases

• Lightning payment requests: the receiver constructs an invoice; the sender's wallet decodes amount/payment-hash/expiry and pays it over the network.[1][2]
• QR scan-to-pay: invoices are commonly uppercased and rendered as a qr-code, or embedded as the lightning= value of a bip-21 unified URI.[1][2]
• On-chain fallback: the optional f field lets an invoice carry a fallback on-chain address.[1]

Implementations

• lightning/bolts — the canonical spec (Markdown); ~2.2k stars, active 2026.[1]
• rust-lightning / lightning-invoice (LDK) — Rust; data structures and bech32 parse/serialise for BOLT11 invoices; rust-lightning ~1.4k stars, active 2026.[4]
• bolt11 (Rust crate) — minimal QR-ready BOLT11 encoder/decoder.[5]
• Zeus — TypeScript Lightning wallet that creates and pays BOLT11 invoices; ~1.4k stars, active 2026.[6]

Comparison

• BOLT11 vs bip-21: bip-21 is a URI wrapper around an on-chain address; BOLT11 is a self-contained, signed, single-use Lightning invoice. The unified QR composes them — a BOLT11 invoice inside a bitcoin: URI's lightning= parameter.[1][2]
• BOLT11 vs BOLT12 offers: BOLT12 ("offers", carried via the lno parameter in BIP 321) targets reusable, static payment codes, whereas a BOLT11 invoice is typically single-use with a fixed payment hash and expiry.[2]
• HRP amount vs amountless invoices: omitting the HRP amount produces an "any amount" invoice where the payer chooses the value; specifying e.g. 2500u fixes it.[1]

Fun facts

• The signature is recoverable: the payer can derive the payee's node public key directly from the invoice signature, so the n (payee node id) field is often redundant.[1]
• BOLT11 borrows Bitcoin's bech32 alphabet wholesale, which is why an lnbc... invoice scans efficiently in a QR code's alphanumeric mode — the same property that motivates uppercasing it in unified QRs.[1][2]

Status

BOLT11 is the active, near-universal Lightning invoice format, implemented by every major Lightning node and wallet (LDK, LND, Core Lightning, Eclair, Zeus, Phoenix, etc.) and supported as the lightning= payload in bip-21 / BIP 321 unified QRs.[1][2][4][6]

Sources

1 BOLT #11: Invoice Protocol for Lightning Payments — lightning/bolts, 2026 2 Unified QRs for Bitcoin — bitcoinqr.dev, 2024 3 BOLT 11 Invoicing — Coinmonks/Medium, n.d. 4 rust-lightning (LDK) — GitHub, 2026 5 bolt11 crate — crates.io, n.d. 6 Zeus — GitHub, 2026

Deployments

No country reports mention this standard by name.

Regions / aggregations not mapped to a single country

• Universal