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. <strong>Route across a network.</strong> 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.

<strong>Liquidity is directional.</strong> 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.

What this establishesLightning batches many state updates into fewer on-chain transactions.

Follow a routed Lightning payment

Ana needs to pay Ben but they do not share a channel. Ana has outbound liquidity to one peer, that peer can forward to another, and the final peer has liquidity toward Ben. The route uses linked conditions so either every hop completes or the attempted payment fails without leaving an intermediate party with the money.

Each hop can charge a base amount and a proportional fee. The participants do not publish the routine payment as a Bitcoin transaction. The payment can still fail when a channel lacks directional liquidity, a route is unavailable, or an invoice is expired. A wallet may retry automatically and hide that complexity.

Channel opening and closing ultimately use the base layer, and backup requirements depend on the wallet's custody model. Fast settlement does not remove the need to understand who controls the keys and how recovery works.

What this establishesPayments can route without trusting intermediaries with the funds.

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.

What this establishesChannel liquidity - not just total balance - affects payment success.

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.