What a Lightning invoice actually is

The short answer

A Lightning invoice is a signed request for one specific payment, with a deadline. The string beginning lnbc encodes a few facts: how much, to whom, under what condition the money may be claimed, and until when. The receiver's node signs it, so a payer can check it was not altered in transit.

It is not an address. It commits to one payment and expires, and those two properties are the point rather than an inconvenience. If channels and routing are new, what the Lightning Network is covers the machinery this string drives.

What the string encodes

The format is BOLT 11. It splits at the first 1 into a human-readable part and a data part.

The human-readable part is a prefix and an optional amount. lnbc is Bitcoin mainnet, lntb testnet. The amount, if present, is a number followed by a multiplier: m for a thousandth of a bitcoin, u for a millionth, n for a billionth, p for a trillionth. The amount is optional by design, because "donation addresses often don't have an associated amount".

The data part is a 35-bit timestamp, then a run of tagged fields, then a signature. The tagged fields worth knowing:

The signature is 520 bits: 64 bytes of R||S plus a one-byte recovery id. It covers everything else, being "a valid compact ECDSA signature over secp256k1 of the SHA-256 hash of: the human-readable part (as UTF-8 bytes) concatenated with the data part (excluding the signature)". The recovery id is why the n field is optional: a payer can recover the payee's public key from the signature itself, so "the identity of the payee node can be implied". This is the same public key cryptography that authorises an on-chain spend, doing a different job.

The r fields matter more than they look. A node whose channels are unannounced appears on nobody's map, so the invoice has to carry directions: if there is no public channel associated with the payee's key, the writer "MUST include at least one r field". That is why an invoice from a private node is noticeably longer.

Why it expires

An invoice with no x field is good for an hour, and that default is doing real work.

The invoice fixes an amount at a moment, points at channels that may close, and commits the receiving node to hold a specific secret and honour a payment claiming it. The spec pushes both sides to stop: a payer, "after the timestamp plus expiry has passed", SHOULD NOT attempt a payment, and a payee, after the same point, SHOULD NOT accept one.

An expiry is not a lock. It is an instruction that well-behaved software on both ends follows.

The payment hash is the receipt

The receiver generates a random number, the preimage, hashes it with SHA-256, and puts the hash in the p field. The money moves along the route only against that number. When the final node releases the preimage, it travels back along the path in update_fulfill_htlc messages, settling each hop as it goes (BOLT 2).

A payer who holds the preimage holds something only the receiver could have produced, matched to an invoice the receiver signed. That pair is the closest thing Lightning has to a receipt, and BOLT 12 is precise about its limit: the proof "can only demonstrate that an invoice was paid (by showing the preimage of the payment_hash), not who paid it. The merchant can claim an invoice was paid, and once revealed, anyone can claim they paid the invoice, too" (BOLT 12). It proves the payment happened. It does not prove it was yours.

What paying a stale one does

Usually, nothing, which is the good outcome. The final node fails the incoming payment, the conditional promises unwind hop by hop, and the money is back in the sender's channel. BOLT 4 makes the recipient's node fail an unrecognised payment: "if the payment hash is unknown: MUST fail the HTLC", and the same for a payment secret that does not match (BOLT 4).

The uncomfortable case is a hash the node still recognises. Where an invoice has already been paid, the spec permits either answer: the final node "MAY treat the payment hash as unknown" or "MAY succeed in accepting the HTLC". Whether a second payment is refused or quietly accepted is left to the receiving software, which is exactly the reason not to reuse one.

The shapes readers actually meet

Most people never paste a BOLT 11 string by hand. Three things stand in front of it, and only one of them is an invoice.

Amountless invoices. The amount is omitted from the human-readable part, and a wallet reading one "SHOULD indicate to the payer that amount is unspecified". Useful for donations and tips. Overpaying is bounded rather than free: a recipient SHOULD fail a payment "more than twice the amount expected" (BOLT 4).

LNURL-pay. A bech32-encoded HTTPS URL, not an invoice (LUD-01). The wallet fetches it and gets JSON back: a callback URL, a minSendable and maxSendable in millisatoshis, and some metadata. The wallet then asks the callback for a specific amount and receives pr, which the specification describes as a "bech32-serialized lightning invoice" (LUD-06). So LNURL is a way to fetch a fresh BOLT 11 every time, not a replacement for one.

Lightning Addresses. The user@domain form, which is LNURL-pay with the URL construction hidden. A wallet seeing [email protected] requests https://bitcoin.org/.well-known/lnurlp/satoshi, and the response "MUST be the same as in LUD-06, step 3, and the flow is the same" (LUD-16).

Both of these buy reusability with a web server. Something has to answer that HTTPS request, so the address stops working when the server does, and the server learns the payer's IP address and what they are about to pay. A Lightning Address is a hostname being trusted to hand over the right invoice.

BIP 353 addresses part of that by moving the lookup into DNS. Payment instructions live in a TXT record at user.user._bitcoin-payment.domain, they "MUST be DNSSEC-signed", and wallets displaying a verified name SHOULD prefix it with a bitcoin symbol to distinguish it from an email address. The BIP says outright that it "is intended to extend and subsume the existing 'Lightning Address' scheme".

BOLT 12 offers, the reusable successor

BOLT 12 replaces the invoice with an offer, a string starting lno1. The offer is the reusable part. A merchant publishes it on a page or a QR code, every payer requests their own invoice over the Lightning Network itself with an invoice_request message, and the merchant answers with a fresh invoice. No web server sits in the middle.

The specification opens by listing what it is fixing, and one item is the subject of this post: BOLT 11 invoices "must be given per user and are actively dangerous if two payment attempts are made for the same user".

Support is uneven, and worth checking before relying on it. Core Lightning ships an offer command that "creates an offer (or returns an existing one), which is a precursor to creating one or more invoices" (Core Lightning, offer). LND does not implement offers itself; operators who want them run LNDK, a separate daemon whose own README described the project as "still experimental" as of August 2026.

What an invoice does not do

It is not an address. An on-chain address is a spending condition that keeps working. An invoice is a request for one payment, and the two are not interchangeable, even when a wallet shows them in the same box.

It is single use. One invoice, one payment hash, one preimage. Reuse leaves the outcome to the recipient's software, which the spec explicitly permits to go either way, and BOLT 12 calls the practice dangerous in as many words.

A Lightning Address is not an invoice. It is a name that fetches one over HTTPS. The distinction stops mattering right up until the server is down.

Where to go next

What happens between the two ends of a payment, and what it costs to keep a channel open at all, is in what the Lightning Network is. Where the keys live while any of this happens is in choosing a wallet.