Lightning Network: Paying in Bitcoin Instantly
Payment channels, routing, invoices, liquidity and fees: understand the Lightning Network and choose between a custodial and a non-custodial wallet.
The essentials
Why Lightning exists
On the Bitcoin blockchain, one block is produced on average every ten minutes and its space is limited. When lots of people want to transact, fees rise and waiting times stretch. For a coffee or a small transfer between friends, that's not practical.
The idea behind the Lightning Network, described in 2016 in a paper by Joseph Poon and Thaddeus Dryja, is simple: rather than recording every payment on the blockchain, two people open a payment channel and exchange as many payments as they want between themselves, off-chain. Only the opening and closing of the channel are recorded on Bitcoin.
Lightning is often described as a "layer 2" of Bitcoin: a system that relies on the main chain's security while moving most of the activity elsewhere.
The payment channel, the basic building block
Opening
To open a channel, two participants lock bitcoin in a shared address that requires both of their signatures to be spent. This opening transaction (funding transaction) is recorded on the blockchain. The locked amount is the channel's capacity.
Updates
Each payment in the channel consists of jointly signing a new split of the balance. Example: Alice has opened a 100,000-sat channel (the satoshi, or "sat," is bitcoin's smallest unit, one hundred-millionth of a BTC). If she pays 10,000 sats to Bob, the new split becomes 90,000 for Alice and 10,000 for Bob. Nothing is published on the blockchain: both parties simply keep the latest signed version.
Closing
At any time, the channel can be closed:
- cooperative close: both parties jointly sign the final split, which is published on the blockchain;
- force close: if the other party stops responding, one of the participants alone publishes the latest signed state. Their funds are then available only after a delay.
Protection against cheating
What happens if someone publishes an old state that was more favorable to them? The protocol provides a penalty: during the closing delay, the wronged party can prove the cheating and take all of the channel's funds. This assumes that they (or a monitoring service, called a watchtower) are watching the blockchain. This is one of the reasons a non-custodial Lightning wallet shouldn't stay offline indefinitely.
Routing: paying someone without a direct channel
Opening a channel with every merchant would be absurd. The Lightning Network therefore links channels together: if Alice has a channel with Bob, and Bob has a channel with Carole, Alice can pay Carole through Bob.
So that Bob can't keep the money along the way, Lightning uses HTLCs (Hash Time-Locked Contracts). In short:
- Carole generates a secret and gives its fingerprint (the hash) in her invoice.
- Each intermediary can only claim its payment by revealing this secret, which only circulates once Carole has been paid.
- If the payment doesn't go through before a deadline, everyone gets their funds back.
According to Lightning Labs' documentation, each payment is atomic: it succeeds entirely or fails entirely. HTLCs also make it possible to settle the payment on the blockchain if an intermediate node becomes unreachable or dishonest.
The sender's wallet has to find a path. Nodes and their channels are known through an information-sharing network (gossip), but not the exact distribution of funds within each channel. The wallet therefore tries several routes until one works, which explains why a payment sometimes fails and then succeeds on retry.
The Lightning invoice
To receive a Lightning payment, you most often generate an invoice, described by the BOLT 11 specification. It starts with lnbc on the main Bitcoin network and is often presented as a QR code. It contains in particular:
- the amount (optional);
- the payment hash, tied to the secret mentioned above;
- a description;
- an expiration date: by default, one hour if nothing is specified;
- the recipient node's signature.
Practical consequences:
- an invoice is designed for a single payment: don't reuse it;
- an invoice expires: if you generate it too early, it will no longer be payable;
- a Lightning invoice is not a Bitcoin address: don't use it for an on-chain send, and vice versa.
Other formats exist for receiving in a reusable way ("Lightning Address" type addresses, for example), but their support depends on the wallet.
Liquidity: why you can't always receive
This is the notion that surprises new users the most.
- Outbound liquidity is your balance in your channels: it lets you send.
- Inbound liquidity is the part of the channel held by the other side: it lets you receive.
According to Lightning Labs, a new node has no inbound capacity until someone has committed funds in a channel toward it. If you open a 100,000-sat channel yourself, you can send up to that amount, but you can't receive until you've spent something.
To get inbound liquidity, the solutions cited by the documentation include: spending sats (which moves the balance to the other side), buying liquidity from node operators, or using swap services between on-chain and Lightning. Many mainstream wallets handle this automatically, often for a fee.
Fees
There are two families of fees:
- On-chain fees, paid when opening and closing channels, which depend on Bitcoin congestion at the time of the operation.
- Routing fees, paid to the intermediate nodes.
Routing fees combine a fixed base fee (expressed in millisatoshis) and a proportional rate expressed in parts per million (ppm). Lightning Labs' documentation gives the example of a payment of one million sats with a base fee of 1,000 msats and a rate of 500 ppm: 501 sats in fees. For small amounts, routing fees are generally very low.
On top of that may come the fees of the service you use (wallet, exchange platform), which each sets freely.
Custodial or non-custodial wallet
| Criterion | Custodial | Non-custodial |
|---|---|---|
| Who holds the keys | The service | You |
| Channel management | Invisible | Automated or manual |
| Main risk | Bankruptcy, account freeze | Error, lost backup |
Custodial: the service holds a balance in your name and manages the channels itself. It's very simple, but you trust that service, exactly as on an exchange platform. Several exchange platforms, incidentally, let you deposit or withdraw bitcoin via Lightning (Kraken, for example, documents this option in its help center): it's a convenient way to fund a wallet without paying on-chain fees.
Non-custodial: you hold your keys. Some apps automate channel opening and liquidity, others require you to run your own node. An important point: backing up a Lightning wallet isn't always limited to the recovery phrase (seed), because channel state matters too. Read the chosen app's backup procedure carefully.
A common compromise is to keep a small "pocket money" amount on Lightning and savings in on-chain bitcoin, ideally on a hardware wallet.
Limits to know
- Amounts: large payments can fail for lack of a route with enough liquidity.
- Availability: a non-custodial wallet generally needs to be online to receive.
- Entry cost: opening a channel costs on-chain fees, sometimes high during congestion.
- Privacy: better than on-chain for payments, but not perfect; a custodial service sees your whole history.
- Complexity: force closes, delays and backups require a minimum of understanding.
A concrete example
Julien wants to pay small amounts in bitcoin and receive reimbursements from friends.
- He installs a non-custodial Lightning wallet and writes down his recovery phrase on paper, checking the app's own channel backup procedure.
- He withdraws 50,000 sats from an exchange platform via Lightning: he generates a 50,000-sat invoice in his wallet and pastes it into the platform. The funds arrive in a few seconds.
- To pay a merchant, he scans the invoice's QR code. His wallet shows the amount, the description and the estimated routing fees before he confirms.
- A friend reimburses him 5,000 sats: Julien generates an invoice for that amount, valid for one hour, and sends it to him.
- For a large amount, he prefers an on-chain send to his hardware wallet.
Mistakes to avoid
- Pasting a Lightning invoice into a Bitcoin address field (or the reverse): check the network chosen, as explained in our guide on sending crypto.
- Reusing an invoice that's already been paid or has expired.
- Storing large amounts on a custodial Lightning wallet.
- Deleting the app of a non-custodial wallet without having closed the channels or checked the backup.
- Paying an invoice without checking amount and description: a scammer can send you an invoice for a different amount.
- Believing a "support" that asks for your seed: no legitimate service asks for it.
This article is general information and is not investment, legal or tax advice.
Key takeaways
- Lightning is a network of payment channels on top of Bitcoin: only the opening and closing of channels are recorded on the blockchain.
- Payments pass through intermediaries thanks to HTLCs and are atomic: they succeed or fail entirely.
- A BOLT 11 invoice is single-use and expires (one hour by default).
- To receive, you need inbound liquidity; many wallets manage it for you.
- Custodial means simplicity but dependence on a third party; non-custodial means control but responsibility.
- Reserve Lightning for small and medium everyday amounts; savings stay better protected on-chain.