Référence du format de facture Lightning BOLT11 : préfixes, champs balisés et règles

Chaque paiement Lightning commence par le même objet : une facture BOLT11. Les portefeuilles l’affichent en code QR; dessous, c’est un conteneur compact et entièrement spécifié de trois parties et onze champs balisés possibles. Cette référence détaille le format champ par champ — ce que chaque balise transporte, sa longueur, sa valeur par défaut et les règles qui font rejeter une facture — d’après la spécification Lightning canonique. Elle prolonge notre référence des BOLT Lightning, de l’index des spécifications jusqu’au format de son document le plus utilisé. Les descriptions par champ sont conservées en anglais.

Réponse rapide

Une facture Lightning BOLT11 (la chaîne lnbc1...) est du bech32 en trois morceaux : une partie lisible (préfixe réseau lnbc/lntb/lntbs/lnbcrt + montant optionnel avec multiplicateur m/u/n/p — l'unité est le bitcoin, pas le satoshi), puis un horodatage de 35 bits, des champs balisés, et une signature ECDSA compacte de 520 bits dont l'identifiant de récupération permet de retrouver l'identité du nœud payé. Cette référence détaille les 11 champs balisés actuellement définis (p/s/d/n/h/x/c/f/r/9/m), leurs longueurs, leurs valeurs par défaut (expiration 3600 s; delta CLTV final 18) et les règles obligatoire/optionnel — dont la règle piquante du multiplicateur p : la dernière décimale DOIT être 0, sinon le montant descendrait sous le millisatoshi. Les descriptions par champ sont conservées en anglais.

Les deux règles qui cassent le plus de paiements : exactement un p ET un s obligatoires (sans s valide, le lecteur DOIT échouer), et exactement un seul de d ou h. La spécification embarque 16 vecteurs de test valides et 10 invalides — la suite de validation de tout décodeur sérieux.

Télécharger le CSV Télécharger le JSON API REST →

Partie lisible : préfixes et multiplicateurs

Préfixe	Réseau
`lnbc`	Bitcoin mainnet
`lntb`	Bitcoin testnet
`lntbs`	Bitcoin signet
`lnbcrt`	Bitcoin regtest

Multiplicateur	Facteur
`m` (milli)	0.001
`u` (micro)	0.000001
`n` (nano)	0.000000001
`p` (pico)	0.000000000001 — la dernière décimale DOIT être 0

Structure de la partie données

1) Horodatage — secondes depuis 1970, 35 bits gros-boutiens. 2) Champs balisés — zéro ou plus, chacun : type (5 bits) + longueur (10 bits) + données (longueur × 5 bits; maximum 639 octets). 3) Signature — ECDSA compacte secp256k1 (64 octets R||S + 1 octet d'identifiant de récupération) sur le SHA-256 de la partie lisible en UTF-8 concaténée à la partie données hors signature, complétée à l'octet.

Les 11 champs balisés

Tag	Nom	Longueur	Signification	Règle
`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 : le texte canonique lightning/bolts 11-payment-encoding.md (consulté le 2026-07-26). Les factures s'encodent en bech32 (BIP-173) sans la limite de 90 caractères; schéma d'URI recommandé : lightning:. Se combine avec la référence des BOLT Lightning et la définition du glossaire. La spécification embarque 16 vecteurs de test valides et 10 invalides — la base de validation d'un futur décodeur navigateur.

Produits, réparations et guides connexes

Dernière révision: 26 juillet 2026.