The Lightning Network is a layer on top of Bitcoin that moves payments off the main chain. Two parties lock bitcoin into a shared channel, then update their balances with signed messages that settle almost instantly. Only opening and closing the channel normally needs a blockchain transaction. Payments can hop across connected channels using hash-locked contracts, so you can pay someone without having a direct channel to them.
Why does Bitcoin need another layer?
Every on-chain Bitcoin payment waits for a new block, which arrives about every 10 minutes on average, and competes for limited block space through fees. Mining sets that rhythm, and it's what keeps the chain secure. It isn't well suited to buying a coffee.
Joseph Poon and Thaddeus Dryja proposed a way around this in their January 2016 paper: send most payments through channels that are enforceable on the blockchain but don't use it day to day. Unlike rollups, Lightning doesn't publish its transactions to the base chain. Individual payments leave no on-chain record unless a channel ends in a dispute.
The network's rules are set out in open specifications called BOLTs, which multiple software teams implement. See our Bitcoin hub for more on the base chain.
How does a payment channel work?
A payment channel is a two-party balance sheet backed by real bitcoin on-chain. It runs in four stages:
- Funding. The parties lock bitcoin in an on-chain output that needs both of their signatures to spend. The size of that output is the channel's capacity.
- Committing. Before anything else, each party holds a signed commitment transaction, a ready-to-broadcast transaction that pays out the current balances. It stays off-chain.
- Updating. To make a payment, they sign new commitment transactions with new balances and hand over the keys that revoke the old ones. No block is needed, so this is why payments are fast.
- Closing. They either cooperate on a final transaction, or one side broadcasts its latest commitment, which is called a force close.
What stops someone broadcasting an old, more favorable balance? The specification delays the broadcaster's own funds by a set number of blocks, called to_self_delay. During that delay, if the commitment was revoked, the other party can use the revocation key to claim those funds right away. Cheating risks losing your balance.
How does a payment cross several channels? A worked example
A hashed timelock contract (HTLC) is a promise that pays if the recipient reveals a secret before a deadline. If the secret isn't revealed in time, the money goes back. Chaining HTLCs lets a payment cross channels without anyone in the middle being able to steal it.
Alice wants to pay Carol 100,000 satoshis (sats). Alice has no channel to Carol, but both have channels with Bob. Bob charges a 1 sat base fee plus 100 parts per million, roughly in line with network medians as of August 2026. Under the standard fee formula, that comes to 1 + 10 = 11 sats.
- Carol creates a secret. She hashes it and puts the hash in her invoice for Alice. The secret itself stays with her.
- Alice offers Bob an HTLC. It says: 100,011 sats are yours if you reveal the secret within 120 blocks.
- Bob offers Carol an HTLC. It says: 100,000 sats are yours if you reveal the secret within 40 blocks. The deadline is earlier so that Bob has time to claim from Alice. The 80-block gap matches the default setting in LND, a widely used Lightning implementation. The deadlines themselves are illustrative.
- Carol reveals the secret to Bob to claim her payment.
- Bob reveals it to Alice to claim his. Each channel then updates its balances.
| Channel balances (sats) | Before | After |
|---|---|---|
| Alice's side of Alice-Bob | 600,000 | 499,989 |
| Bob's side of Alice-Bob | 400,000 | 500,011 |
| Bob's side of Bob-Carol | 700,000 | 600,000 |
| Carol's side of Bob-Carol | 300,000 | 400,000 |
No blockchain transaction happened, and the whole thing normally takes seconds. Bob gained 11 sats overall. If Carol never reveals the secret, the HTLCs simply expire, and everyone keeps what they started with. (This ignores the small reserve each side must keep in a channel.)
Privacy comes from onion routing. Alice wraps the route in encrypted layers, and each hop can learn only the node before and after it. So Bob doesn't know from the packet whether Alice is the true sender, or whether Carol is the final recipient.
Why do liquidity and inbound capacity matter?
Channel capacity doesn't tell you how much can move in a given direction, and this surprises many new users. In the table above, Bob could forward at most 700,000 sats to Carol at the start, because that's what was on his side. Sats on your own side are your outbound capacity, and sats on the other side are your inbound capacity.
This has practical consequences:
- A new channel you funded can't receive at first. All the sats are on your side. You build inbound capacity by spending, by swapping funds back on-chain, or by getting others to open channels to you, sometimes paying them for it.
- Routes fail because balances are hidden. Channel announcements reveal channels but not how funds are split. Senders may try several routes before one works.
- Large payments are harder. Each hop needs enough on the right side. Multi-part payments help by splitting one payment across routes, and the recipient accepts all parts or none.
- Channels have size limits by default. The protocol caps channels below 2^24 sats (about 0.168 BTC) unless both nodes opt in to larger ones. As of late August 2026, the median public channel held about 2 million sats.
Custodial vs. non-custodial Lightning
In a custodial service, a company runs the channels and you hold a balance with it. In a non-custodial one, you hold the keys. The difference matters more on Lightning than most other places, because channels need ongoing care.
| Custodial (an exchange or app holds funds) | Non-custodial (you hold keys) | |
|---|---|---|
| Who controls the bitcoin | The provider | You, through your node or wallet |
| Inbound capacity | Handled by the provider | Your job, or your wallet provider's service |
| Being offline | No channel risk for you | Needs a watchtower, or a wallet that handles this |
| Main risk | Provider failure, freezes or rules | Lost backups, missed disputes, closing fees |
Phoenix, for example, describes itself as self-custodial, so losing the recovery phrase means losing the funds. Our guides on wallet custody and seed phrases cover the general trade-off. Products change their custody model over time, so check a wallet's current documentation. Don't rely on a list.
What are watchtowers, and what does a force close cost?
A watchtower is a service that watches the chain for a revoked commitment and broadcasts the penalty if it sees one. It exists because you can only punish a cheater during the delay window, and you might be offline. According to Bitcoin Optech, watchtowers are not entrusted with the funds they monitor. In LND's software, you can run or connect to one, and these towers are altruistic, with no built-in payment.
A force close has two costs, time and fees.
Time. Your funds are locked for to_self_delay. LND scales this with channel size, from 144 to 2,016 blocks, or roughly one day to two weeks.
Fees. The specification's weights put a commitment using anchor outputs, a common format that lets either side add fees later, at 1,124 weight units, or 281 virtual bytes (vB), plus 43 vB for each pending HTLC. The party who funded the channel pays that fee. Later transactions, to sweep your funds and to resolve each HTLC, add more. For the commitment alone:
| Bitcoin fee rate | Commitment cost |
|---|---|
| 1 sat/vB (typical in October 2026) | 281 sats |
| 50 sat/vB | 14,050 sats |
| 500 sat/vB | 140,500 sats |
The high end isn't hypothetical. Mempool.space data shows median block fee rates above 1,000 sat/vB in a burst on April 20, 2024. At that level, closing a 100,000-sat channel could cost more than the channel holds.
This also limits very small payments. An HTLC too small to justify its own on-chain output gets trimmed, meaning it isn't enforceable on-chain. The amount at which that happens rises with fees.
What are the limits?
Lightning trades on-chain simplicity for speed, and the trade has real costs:
- You must stay vigilant, directly or through a tower or wallet service. Channels aren't "set and forget".
- It depends on Bitcoin's block space. If many channels had to close at once during a fee spike, some might not be able to settle in time.
- Known attacks exist. Channel jamming ties up a channel's pending-payment slots, which are capped at 483 on standard channels. Replacement cycling, disclosed in October 2023, can in some conditions let an attacker steal forwarded funds. Implementations have deployed mitigations.
- Reliability isn't guaranteed. Payments can fail for lack of a route, especially large ones.
- It's only as private as the route. Onion routing hides a lot, but your channel partner and a provider's service can see some activity.
How much is Lightning actually used?
Usage data is patchy: the best volume estimates stop in late 2025, and public capacity has fallen since then. River estimated that monthly volume passed $1 billion in 2025 and that the average transaction reached $223. Cointelegraph's report of River's data put November 2025 at about $1.1 billion across 5.2 million transactions, driven largely by exchanges and businesses. Transaction counts were still below an August 2023 peak of 6.6 million.
Public capacity tells a different story. Mempool.space's data shows roughly 3,800 BTC across about 32,700 channels on August 30, 2026, the latest snapshot available as this was written, down from about 5,650 BTC in late December 2025. Other trackers report different totals, because each sees the network differently and private channels aren't counted. Volume figures are estimates, and neither number proves how many people use Lightning for everyday purchases. To see the on-chain side of a channel open or close yourself, you can read it on a block explorer. Our scaling hub covers other approaches.
Key takeaways
- Lightning moves payments into two-party channels, so only opening and closing normally touch the blockchain.
- HTLCs let a payment cross several channels safely: reveal the secret in time and get paid, or the money returns.
- Inbound capacity decides how much you can receive, and hidden balances are why some routes fail.
- Custodial wallets are simple but require trusting a provider. Self-custody needs backups and a plan for disputes.
- Force closes lock funds for a delay and cost on-chain fees, which can be trivial or severe depending on Bitcoin's fee market.
- Estimated volume passed $1 billion a month in late 2025, and public capacity then fell through August 2026, so read either number carefully.
Sources
Get the weekly commit
New blockchain deep dives every week.
