The Lightning Network

Move activity off chain

Two parties lock bitcoin into a base-layer channel and exchange updated commitments without publishing every payment. The eventual settlement reflects the final channel state, reducing routine demand for block space.

Route across a network

A payer need not share a direct channel with the recipient. Hash time-locked contracts coordinate atomic multi-hop routes so intermediaries forward value without taking custody of the payment.

Name the layer and the actor. Wallets create transactions, nodes check rules, miners propose blocks, and Lightning peers manage channels.

Liquidity is directional

A channel balance determines how much can be sent or received in each direction. Wallets may automate channel and liquidity management, but reliability, fees and privacy still depend on topology and implementation.

Channels and routes

Two parties open a channel by locking bitcoin in a shared on-chain transaction. They can then pay each other any number of times by exchanging signed updates that reassign the balance, none of which touch the chain.

To pay someone you have no channel with, your node finds a path through other channels — you to Alice, Alice to Bob, Bob to the shop — and a cryptographic construction ensures every hop either completes or none does.

Each hop needs enough balance on the correct side of its channel, which is what 'liquidity' means in Lightning and why a payment sometimes fails and retries along another route.

Using it well

A custodial Lightning wallet holds your balance for you and works instantly; it is an account, with the trust that implies. A non-custodial wallet runs a node on your device, opens channels with your coins, and needs a small on-chain transaction and some inbound liquidity before it can receive.

Keep the amount on Lightning to what you spend, not what you save; treat channel balances as a hot wallet. Back up the static channel backup file the wallet produces, and understand that a force-close by a peer returns your funds on-chain after a delay rather than instantly.

What it does and does not solve

Lightning makes small, frequent payments practical: sub-second settlement, fees of a few satoshis, and no block space consumed per payment. It does not remove the base layer's limits, because opening and closing channels are on-chain transactions, and it does not suit large one-off transfers, which are cheaper and simpler on-chain.

Routing large amounts is unreliable, both parties must be online, and the privacy model differs from on-chain in ways that cut both directions. The Lightning explorer on this site shows public network capacity and channel counts as a gauge of how much economic activity has moved there.

Test the payment path carefully

Use a small payment to learn how invoices, liquidity, routing, timeouts, and channel backups behave. Keep the on-chain recovery path clear before depending on a Lightning wallet.