BOLT11 invoice

Every Lightning payment starts with one of these. The invoice commits to a 256 bit payment hash that only the recipient can unlock, and it expires after one hour unless the issuer says otherwise, which is why a screenshot of an old QR code is useless. Paying one is safe in the sense that the money either reaches the named node or comes back to you.

How it works

A BOLT11 invoice is a bech32 string with a prefix that names the network and a body made of tagged fields.

The prefix, called the human readable part, is lnbc on mainnet, lntb on testnet, lntbs on signet and lnbcrt on regtest. Immediately after it comes the amount, written as a number plus a multiplier letter: m for thousandths of a bitcoin, u for millionths, n for billionths and p for trillionths. So lnbc2500u asks for 0.0025 bitcoin. Leaving the amount out entirely produces an open invoice that the payer fills in.

The body is a sequence of tagged fields, each one a single character tag, a length, and a value. The mandatory one is the payment hash, 256 bits written as 52 bech32 characters. Then come the optional ones: a description or, for long descriptions, a hash of the description; an expiry, defaulting to 3600 seconds; a minimum final CLTV expiry delta, defaulting to 18 blocks, which is the safety margin the recipient wants on the last hop; a payee node id; a fallback on-chain address; and routing hints that tell the payer how to reach a node whose channels are unannounced.

The whole thing is signed. The signature is 520 bits, a 64 byte value plus one recovery byte, which is what allows a wallet to derive the paying destination from the invoice even when no node id field is present. A six character bech32 checksum sits on the end, so a mistyped character is caught rather than sending money into nothing.

The payment hash is the mechanism that makes an invoice more than a text file. The recipient generates a random preimage, hashes it, and puts the hash in the invoice. Every hop along the route locks its forwarded amount to that same hash, and only revealing the preimage releases the money. A settled payment therefore leaves the payer holding a preimage that hashes to the invoice, which is a cryptographic receipt no merchant can plausibly deny.

Why this matters when you buy bitcoin

An invoice is where several avoidable mistakes happen when you are withdrawing from an exchange.

The first is the expiry. Exchange withdrawal flows can take minutes to process, and an invoice generated at the start of a slow flow may be dead by the time it is paid. If a Lightning withdrawal fails with no obvious reason, regenerate the invoice in your wallet before assuming the exchange broke. The default is one hour, but wallets that expect fast payments often set it to ten or fifteen minutes.

The second is the amount. An invoice with an amount in it can only be paid for that amount, which is exactly what you want, because it removes the possibility of typing an extra zero. An invoice without an amount, sometimes called an open or zero-amount invoice, is convenient for donations and dangerous in a withdrawal flow. Prefer the version with the number baked in.

The third is reuse. A BOLT11 invoice is single use by design. Publishing one on a donations page means the second donor's payment either fails or, on a badly built receiver, pays the first donor's hash again. This is precisely the problem BOLT12 offers were designed to solve, which is why that specification was merged into the Lightning standard in September 2024, the first new BOLT since 2017. Until your wallet and your counterparty both support offers, a Lightning address is the practical way to publish a reusable destination.

Finally, check the exchange actually supports Lightning before you plan around it. Strike, which we review, supports withdrawals over both Lightning and on-chain. Plenty of the platforms in our exchange comparison do not, and on those the cheapest way to move small amounts is not to move them often.

Reading an invoice field by field

Take a short invoice apart and it stops looking like noise.

A string beginning lnbc1500n tells you two things before you decode anything: it is a mainnet invoice, and it is asking for 1500 nanobitcoin, which is 0.0000015 bitcoin, or 150 satoshis. What follows is a timestamp, then the tagged fields. A d field carries a short description such as "table 4"; an x field of 600 would set the expiry to ten minutes instead of the default hour; a c field would override the 18 block final CLTV delta if the recipient wants a bigger safety margin.

If the recipient's node has no public channels, an r field carries a routing hint: the node id of a well connected peer, the short channel id to use, and that peer's fee and delta. Without it, your wallet would look at the public graph, see no path, and give up. This is why invoices from mobile wallets are often noticeably longer than invoices from big public nodes.

BOLT11 invoice vs Bitcoin URI

A BOLT11 invoice is a Lightning payment request; a Bitcoin URI is an on-chain payment request. The URI form, bitcoin: followed by an address and optional parameters, points at the blockchain and can be paid by any wallet, any number of times, with any amount. An invoice points at a node, expires, and is meant to be paid once. Wallets increasingly show a unified QR code that carries both, so a payer can choose, but the two payloads are separate standards with separate failure modes.

BOLT11 invoice vs Lightning address

A BOLT11 invoice is the payment request itself; a Lightning address is a way to go and fetch one. Typing an address like you@example.com into a wallet triggers an HTTPS request to that domain, which replies with a freshly generated BOLT11 invoice for the amount you chose. The address is reusable and human readable because it is not a payment request at all: it is a pointer to a server that will mint one on demand.