# BOLT11

> Source: https://docs.barcoder.ai/docs/standards/bolt11
> research date 2026-06-03 · extracted at 2026-10-06
> Publisher: Barcoder — encyclopedia of QR, barcode and payment-code standards

Specifications:
- [BOLT #11: Invoice Protocol for Lightning Payments](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md)
- [The Lightning Invoice (bolt11.org)](https://www.bolt11.org/)

## 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.<sup>[1][1]</sup> "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.<sup>[1][1]</sup> Because a BOLT11 string is compact and bech32-checksummed, it is "QR-code-ready" and is routinely rendered as a [QR Code](https://docs.barcoder.ai/docs/standards/qr-code) or embedded in a [BIP-21](https://docs.barcoder.ai/docs/standards/bip-21) `lightning=` parameter for scan-to-pay.<sup>[1][1]</sup><sup>[2][2]</sup>

## 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).<sup>[1][1]</sup> It reuses Bitcoin's bech32 encoding (BIP-173) both for its checksum and for the currency-prefix scheme in its human-readable part.<sup>[1][1]</sup><sup>[3][3]</sup> 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.<sup>[1][1]</sup>

## Technical specification

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

**Human-readable part (HRP):**<sup>[1][1]</sup><sup>[3][3]</sup>

- *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`):<sup>[1][1]</sup>

- *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:**<sup>[1][1]</sup>

| 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):<sup>[1][1]</sup>

```
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.<sup>[1][1]</sup><sup>[2][2]</sup>
- **QR scan-to-pay**: invoices are commonly uppercased and rendered as a [QR Code](https://docs.barcoder.ai/docs/standards/qr-code), or embedded as the `lightning=` value of a [BIP-21](https://docs.barcoder.ai/docs/standards/bip-21) unified URI.<sup>[1][1]</sup><sup>[2][2]</sup>
- **On-chain fallback**: the optional `f` field lets an invoice carry a fallback on-chain address.<sup>[1][1]</sup>

## Implementations

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

## Comparison

- **BOLT11 vs [BIP-21](https://docs.barcoder.ai/docs/standards/bip-21)**: [BIP-21](https://docs.barcoder.ai/docs/standards/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.<sup>[1][1]</sup><sup>[2][2]</sup>
- **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.<sup>[2][2]</sup>
- **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.<sup>[1][1]</sup>

## 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.<sup>[1][1]</sup>
- 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.<sup>[1][1]</sup><sup>[2][2]</sup>

## 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](https://docs.barcoder.ai/docs/standards/bip-21) / BIP 321 unified QRs.<sup>[1][1]</sup><sup>[2][2]</sup><sup>[4][4]</sup><sup>[6][6]</sup>

## Sources

[1]: https://github.com/lightning/bolts/blob/master/11-payment-encoding.md
[2]: https://bitcoinqr.dev/
[3]: https://medium.com/coinmonks/bolt-11-invoicing-cfe178abb17c
[4]: https://github.com/lightningdevkit/rust-lightning
[5]: https://crates.io/crates/bolt11
[6]: https://github.com/ZeusLN/zeus

[1] [BOLT #11: Invoice Protocol for Lightning Payments](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md) — lightning/bolts, 2026
[2] [Unified QRs for Bitcoin](https://bitcoinqr.dev/) — bitcoinqr.dev, 2024
[3] [BOLT 11 Invoicing](https://medium.com/coinmonks/bolt-11-invoicing-cfe178abb17c) — Coinmonks/Medium, n.d.
[4] [rust-lightning (LDK)](https://github.com/lightningdevkit/rust-lightning) — GitHub, 2026
[5] [bolt11 crate](https://crates.io/crates/bolt11) — crates.io, n.d.
[6] [Zeus](https://github.com/ZeusLN/zeus) — GitHub, 2026

## Deployments

_No country reports mention this standard by name._

## Regions / aggregations not mapped to a single country

- Universal