A Lightning invoice starts with lnbc (or lntb on testnet), is long — usually 200 to 400 characters — and describes one specific payment: amount, expiry and recipient node. A Bitcoin on-chain address starts with bc1, 3 or 1, is 26 to 62 characters long, and can receive any amount at any time. They are not interchangeable. A swap service, an exchange deposit or a hardware wallet that asks for a Bitcoin address needs the second; a Lightning wallet paying a merchant needs the first.
Side by side
| Lightning invoice (BOLT11) | On-chain address | |
|---|---|---|
| Prefix | lnbc, lntb, lnbcrt; BOLT12 offers start with lno | bc1q, bc1p, 3, 1 |
| Length | ≈ 200–400+ characters | 26–62 characters |
| Amount | usually encoded in the invoice | never encoded; sender chooses |
| Expiry | yes, default 1 hour | no |
| Reuse | single payment | technically reusable (not recommended for privacy) |
| Paid by | a Lightning wallet | any Bitcoin wallet or exchange withdrawal |
Reading the amount inside an invoice
The part right after lnbc encodes the amount with a multiplier letter: m for milli (0.001 BTC), u for micro (0.000001 BTC), n for nano and p for pico. So lnbc25u is 25 micro-bitcoin, which is 2,500 satoshis; lnbc1m is 0.001 BTC, or 100,000 sats. An invoice that has only lnbc1 followed by data has no amount and lets the payer choose. The Lightning invoice decoder reads the amount, expiry, description and payment hash in your browser without sending the invoice anywhere.
- lnbc2500n — 2,500 nano-BTC = 250 sats
- lnbc10u — 10 micro-BTC = 1,000 sats
- lnbc500u — 500 micro-BTC = 50,000 sats
- lnbc1m — 1 milli-BTC = 100,000 sats
What else an invoice contains
After the amount, the invoice holds a timestamp and a set of tagged fields, followed by the recipient node's signature. The fields that matter to a payer are the payment hash (the lock that the payment releases), the description or its hash (what you are paying for), the expiry, the minimum final CLTV delta used for routing and, sometimes, route hints that help reach a private node and a fallback on-chain address. A decoder shows all of them in plain form. If the description says something different from what the merchant promised, do not pay.
Because the signature covers the whole invoice, changing even one character makes it invalid. That protects against simple tampering in transit, but not against an attacker who swaps the whole invoice for their own, which is why the description and amount are worth checking on the paying device.
Why invoices expire
An invoice carries a payment hash, and the recipient's node keeps the matching secret only for a limited time. By default a BOLT11 invoice is valid for 3,600 seconds after creation; merchants often set 10–15 minutes so that the dollar price does not drift. After expiry wallets refuse to pay it. If you see “invoice expired”, ask the recipient for a new one — never try to pay an old invoice by other means.
Unified QR codes
Many merchants show a single QR code that contains both formats: a BIP21 URI such as bitcoin:bc1q…?amount=0.0001&lightning=lnbc10u…. A Lightning wallet reads the lightning parameter; an on-chain wallet uses the address. That is convenient for paying a merchant, but if you scan such a QR into a form that needs an address, make sure the form picks up the bc1… part and not the invoice. The Bitcoin QR code generator makes on-chain QR codes with an optional amount.
What goes into a KOT.CASH swap form
- For a BTC payout, paste an on-chain address from your own wallet: bc1q…, bc1p…, 3… or 1…. The address validator checks the checksum.
- An invoice pasted into the address field is rejected: KOT.CASH does not pay out over Lightning.
- For a BTC deposit, the order page shows an on-chain deposit address. A Lightning wallet cannot pay it directly unless the wallet supports sending to on-chain addresses (via a swap).
- If your BTC is on Lightning, see moving bitcoin from Lightning to on-chain first.
Lookalikes and mistakes
- lnurl1… and Lightning addresses (name@domain). These are not invoices either; a wallet resolves them to an invoice. See Lightning address and LNURL.
- Liquid addresses (lq1…, VJL…, ex1…) belong to the Liquid sidechain, not to Bitcoin on-chain.
- Testnet addresses (tb1…, m…, n…, 2…) and testnet invoices (lntb…) carry worthless coins.
- Bitcoin Cash addresses (bitcoincash:q…) look different but legacy BCH addresses starting with 1 look exactly like Bitcoin legacy addresses.
Which address type to give for BTC payouts
Native SegWit (bc1q…) addresses are accepted almost everywhere and are cheap to spend from later. Taproot (bc1p…) is slightly cheaper still for single-signature spending, and KOT.CASH payouts support it, but a few older services cannot send to it. Legacy (1…) and nested SegWit (3…) addresses work but cost more to spend. When a service gives you a choice, bc1q is the safe default.
FAQ
Can I send on-chain BTC to a Lightning invoice?
Not directly. Some invoices include a fallback on-chain address, and some wallets swap automatically; otherwise ask for an on-chain address.
What does lnbc mean?
ln for Lightning, bc for Bitcoin mainnet. Testnet invoices start with lntb.
How long is a Lightning invoice valid?
By default one hour after creation; the creator can set a shorter or longer expiry.
Can I reuse a Lightning invoice?
No. A BOLT11 invoice is for one payment. BOLT12 offers (lno…) and Lightning addresses are reusable.
Does KOT.CASH accept Lightning invoices?
No. Use an on-chain Bitcoin address for BTC payouts.