Lightning Network Total Capacity
- 1M1M
- 3M3M
- 6M6M
- 1Y1Y
- ALLALL
- LinearLinear
- LogLog
About this metric
What it measures
Lightning Network Total Capacity adds up the BTC committed to publicly announced payment channels, counting each channel once rather than once for each endpoint. Measured in BTC, it records the stock of capital backing public channels, not the value of payments sent through them.
How to read it
An increase means more BTC is committed to the observed public channel network, while a decline means that capital stock has contracted. Capacity rose from about 930 BTC at the May 2020 halving to about 4,720 BTC at the April 2024 halving; its recorded peak was about 5,902 BTC on December 28, 2025. These changes describe the scale of channel funding rather than payment activity.
Private channels are not included, so the figure is not a complete total for all Lightning funds. Public capacity also does not reveal how balances are split between channel endpoints: usable liquidity depends on payment direction, routing and channel availability. A few large channel openings or closures can move the total, and a BTC price change alters its dollar value without changing capacity in BTC.
- Frequency
- Daily (UTC 00:00)
- Asset
- BTC
- Category
- Lightning Network
- Type
- Single value
- Unit
- BTC
- Data since
- 2018-01-26
- Latest data
- 2026-10-27
- Data points
- 3,197
FAQ
Is Lightning Network capacity the same as payment volume?
No. Capacity is the BTC held in channels at a point in time; payment volume is the amount transferred over a period. The same channel funds can support repeated payments, so volume cannot be inferred from capacity alone.
Why can total capacity rise while the number of channels falls?
Total capacity depends on channel size as well as channel count. Replacing several small channels with fewer, larger channels can increase the BTC total even as the count declines.
Does total capacity show how much BTC I can send or receive?
No. A channel's total capacity combines funds on both sides, while sending requires outbound liquidity and receiving requires inbound liquidity. A payment across several channels also needs a route with enough liquidity in the required direction.
