The Lightning Network is a layer 2 payment network for Bitcoin in which participants open payment channels secured by on-chain transactions and then exchange an unlimited number of off-chain payments that settle on the blockchain only when a channel closes. Payments can travel across several channels, so two users can pay each other without a direct channel between them.
In blockchain scaling, the Lightning Network is the leading example of a state channel network. It increases payment throughput and cuts fees by moving most activity off the base layer, while keeping the ability to enforce the latest balance on-chain if a counterparty misbehaves.
How Lightning payment channels work
A channel starts with a funding transaction: two parties lock bitcoin into a 2-of-2 multisignature output on the blockchain. Both then hold signed but unpublished commitment transactions that describe how the locked funds would be split if the channel closed now. Every payment replaces the current commitment with a new one that shifts the balance.
The protection against cheating is the revocation mechanism. When a new state is agreed, each party hands over a secret that invalidates its previous commitment. If one side later publishes an old, more favorable state, the other side can use the revealed secret within a time-locked dispute window to claim the entire channel balance as a penalty. This is why a node must monitor the chain or delegate monitoring to a watchtower service.
A channel can end in three ways. A cooperative close publishes one transaction agreed by both parties. A force close publishes the latest commitment unilaterally and waits for the timelock to expire. A penalty close occurs when a revoked state is detected and punished.
Routing payments across the network
Most payments travel through multiple hops. The sender’s software finds a path through public channels that have enough liquidity in the right direction, then uses onion routing so that each intermediate node learns only its predecessor and successor, not the full route.
Atomicity comes from hash time-locked contracts, or HTLCs. The recipient creates a secret and shares its hash in the invoice. Each hop forwards funds that can be claimed only with that secret before a deadline. When the recipient reveals the secret to claim payment, it flows back along the route, and every hop can claim its incoming funds. Either the whole payment succeeds or none of it does.
| Parameter | Typical value or range | What it affects |
|---|---|---|
| Base fee | 0 to about 1 satoshi per hop | Fixed cost of forwarding |
| Fee rate | A few to several hundred parts per million | Cost proportional to amount |
| CLTV delta | Roughly 18 to 144 blocks per hop | Time a node needs to react to failures |
| Channel capacity | From tens of thousands of satoshis to several bitcoin | Maximum amount the channel can move |
| Dispute window | Often about 144 to 2,016 blocks | Time to punish a revoked state |
Large payments can be split with multi-path payments, which send parts over several routes at once. This helps when no single path has enough liquidity.
Liquidity and channel management
Liquidity is the central operational constraint of the Lightning Network. Funds in a channel sit on one side or the other: outbound liquidity lets a node send, while inbound liquidity lets it receive. A new merchant node with only outbound liquidity cannot accept payments until someone opens a channel toward it or until it shifts balance.
| Tool | What it does | Trade-off |
|---|---|---|
| Circular rebalancing | Pays oneself through the network to shift balance | Costs routing fees |
| Submarine swap | Exchanges on-chain bitcoin for channel balance | On-chain fee and swap fee |
| Splicing | Adds or removes funds without closing the channel | Requires on-chain transaction |
| Liquidity purchase | Pays a provider to open an inbound channel | Lease cost and counterparty choice |
| Dual-funded channel | Both parties contribute funds at opening | More coordination at setup |
Mobile wallets often hide this complexity by relying on a service provider that manages channels for the user. This improves usability but can reduce the degree of self-custody and privacy, so the choice of wallet is a trust decision as much as a convenience decision.
Lightning compared with other scaling approaches
The Lightning Network scales payments between known parties well but is not a general-purpose execution layer. The comparison below places it among neighboring approaches.
| Approach | Where state lives | Best suited for | Main limitation |
|---|---|---|---|
| Lightning Network | Off-chain between channel parties | Frequent small Bitcoin payments | Liquidity and online requirements |
| Rollup | Batched on a layer 2 with data posted to layer 1 | General smart contracts | Sequencer trust and data costs |
| Sidechain | Separate chain with its own consensus | Experimentation and features | Security depends on the sidechain |
| On-chain Bitcoin | Every transaction in a block | Large or long-term transfers | Limited throughput and variable fees |
Limitations and risks
- Nodes must stay online or use a watchtower to detect cheating within the dispute window.
- Force closes can be expensive when on-chain fees are high, and funds stay locked until the timelock expires.
- Routing failures occur for large payments when no path has enough liquidity.
- Backup is harder than for on-chain wallets, because a seed phrase alone does not restore the current channel state.
- Privacy is partial. Onion routing hides routes, but public channels and probing can reveal balances and patterns.
- Mass channel closures during fee spikes could congest the base layer, a scenario often discussed as a systemic risk.
These limits explain why Lightning suits small and medium everyday payments best, while large transfers and long-term storage usually remain on the Bitcoin base layer.
A non-technical view
Imagine two friends who eat lunch together every day. Instead of paying each other cash after each meal, they keep a shared tab and settle up only at the end of the month. The Lightning Network does this for bitcoin payments, with the blockchain acting as the final referee.
Because tabs can be chained together, you can also pay someone you have no tab with, as long as friends of friends connect you. Payments arrive in seconds and usually cost a tiny fraction of a cent.
A concrete example
A small coffee shop wants to accept bitcoin without waiting ten minutes or more for a block confirmation. It runs a Lightning node and buys a 2,000,000-satoshi inbound channel from a liquidity provider so that customers can pay it from the first day.
A customer pays for a 4-dollar coffee by scanning an invoice with a mobile wallet. The payment crosses three hops, settles in about two seconds and costs the customer a few satoshis in routing fees. At the end of each week, the shop uses a submarine swap to move accumulated balance to its on-chain savings wallet, which restores inbound capacity for the next week. Over a month, the shop handles hundreds of payments while making only a few on-chain transactions, which is exactly the efficiency gain the network is designed to deliver.