Lightning Network

Lightning is the part of Bitcoin that confuses smart people. They hear “network” and assume it must be a separate coin, a sidechain, or some Bitcoin spinoff. It is none of those. Lightning is a payment layer on top of Bitcoin — same BTC, same keys, just a way to move value without writing every transaction to the base chain. I have run my own Lightning node since 2019, plus Phoenix on my phone, and I have watched the network grow from a curiosity into infrastructure that handles real payments every second.

This page explains what you are looking at on the dashboard, why the numbers matter, and what they do not tell you.

Lightning is Bitcoin, just faster

There is no “Lightning coin.” When you fund a Lightning channel, you send real BTC to a 2-of-2 multisig address on the base chain. That BTC sits there, owned jointly by you and your channel partner, until the channel closes — which writes a final settlement back to L1.

Everything in between — every payment, every routing hop, every podcast micro-transaction — is the two parties signing new versions of the same multisig output, agreeing on who owns what. No miner sees these updates. They are off-chain but cryptographically enforceable on-chain at any time.

The core trick: Bitcoin’s base layer is the court, Lightning is the contract. You only go to court when you need to.

The channel

Alice and I open a channel by jointly funding a 2-of-2 multisig. Say I put in 1,000,000 sats; Alice puts in nothing. The opening transaction confirms on-chain. We now share a “commitment transaction” saying 1,000,000 sats are mine, 0 are Alice’s.

When I pay her 50,000 sats, we sign a new commitment: 950,000 to me, 50,000 to her. The old commitment is invalidated by exchanging revocation keys. Either of us can publish the latest commitment and walk away with our share. If one of us cheats and publishes an old, more favorable state, the other uses the revocation key to claim the entire channel balance as penalty.

That penalty mechanism is what makes the trust model work. Cheating costs everything.

The graph

A channel is two parties. The network is tens of thousands of channels stitched together. Each public node announces its channels via gossip protocol — that is how mempool.space and 1ml.com build the dashboard. When I pay someone four hops away, my node finds a path A → B → C → D and constructs a payment that traverses it.

The trick is HTLCs — Hashed Time-Locked Contracts. The recipient generates a secret, hashes it, and sends me the hash. I tell each hop: “I will release these sats if you produce the preimage within X blocks.” Each hop only forwards if the next commits the same way. When the recipient reveals the preimage, the secret cascades back up the route, and every hop atomically settles.

Either the whole payment succeeds or none does. No hop can steal mid-route — funds release only against the preimage.

Why it works

Three properties make Lightning useful:

• Instant. Channel updates take milliseconds to seconds. No 10-minute block wait.
• Cheap. Routing fees are typically a few sats or fractions thereof. Marginal cost of a payment is essentially zero.
• Scalable. Throughput is bounded by channels, not by Bitcoin’s 1MB blocks. A single channel can handle thousands of payments per second.

The cost is locked-up capital — sats sit in multisig until the channel closes. Capital efficiency traded for transaction efficiency.

The numbers on this dashboard

The headline figures:

• Public capacity: 5,000–7,000 BTC range as of late 2024 into 2026 — total BTC in publicly announced channels.
• Channel count: ~50,000 to 70,000 public channels.
• Node count: ~17,000 to 20,000 public nodes.
• 30-day delta: rolling growth signal. Positive means new capacity; negative usually means consolidation or closures.

These come from the gossip protocol, scraped by mempool.space and 1ml.com. Accurate for what they measure — but what they measure is incomplete.

Public vs private channels

Here is where the dashboards lie by omission.

Public channels are announced; their capacity and fee policies gossiped to every node. This is how routing works.

Private channels (unannounced) are invisible. Most mobile wallets — Phoenix, Wallet of Satoshi, Breez, Mutiny — open private channels to their service nodes. The user sends and receives, but the channel never appears in the public graph.

Private channels are growing fast. Phoenix alone has hundreds of thousands of users, each with a channel to ACINQ. Real Lightning capacity in active use is likely several multiples of the public figure. Read “5,500 BTC of public capacity” as a floor, not the truth.

Custodial vs non-custodial

A spectrum, not a binary:

• Custodial. Wallet of Satoshi, Strike. They run nodes; you have an account balance. Easy onboarding, but they can freeze, lose, or get shut down. Not your keys, not your coins.
• Non-custodial mobile. Phoenix, Breez, Mutiny, Zeus. You hold the keys. The wallet automates channel management, usually for a small premium.
• Self-hosted. LND, Core Lightning (CLN), Eclair. Full control, full responsibility — you manage liquidity, channel partners, and uptime. This is what node-runners and merchants run.

I use Phoenix on my phone for daily payments and a personal Eclair node for routing experiments.

Liquidity is the real problem

Capacity is not the same as usable liquidity. A channel has two sides:

• Outbound liquidity — your sats on your side. What you can spend.
• Inbound liquidity — your counterparty’s sats on their side. What you can receive.

A channel funded entirely by you has 100% outbound and 0% inbound. You cannot receive anything until you spend something out first. For merchants, this is the central operational headache.

Services like Magma (Amboss), Lightning Pool, and various LSPs (Lightning Service Providers) let you buy inbound liquidity — pay a fee, get a channel opened to you with sats already on the other side. Phoenix builds this into its UX with splicing and just-in-time channels, abstracting the problem at the cost of a small fee per inbound payment.

Routing in practice

Most payments under 100,000 sats route in seconds across two to five hops. Pathfinding (Dijkstra-style with fee + reliability weights) picks a route balancing cost and success probability.

For larger payments, MPP (Multi-Part Payments) splits a payment across multiple parallel routes. A 5 million-sat payment might travel as ten 500,000-sat shards through ten paths. HTLCs are atomic at the recipient: either all shards arrive and the preimage is revealed, or none settle.

This is also why Lightning is bad for transferring whole bitcoins. The base chain handles those better.

Why fees are tiny

A typical on-chain transaction costs $0.50 to $5+ depending on mempool conditions. A typical Lightning payment costs less than a cent. The reason is structural: the only marginal cost of routing is bandwidth and the opportunity cost of routed liquidity. There is no block space competition. Routing nodes set fees based on utilization; competition keeps them low.

What can go wrong

The main failure mode is force-closure. Your counterparty goes offline or you suspect cheating, so you publish the latest commitment unilaterally. Sats are safe but locked behind a 144-block (~24-hour) timelock — a safety window in case the counterparty tries to publish an older state. You also pay an on-chain fee, which on a busy day can be substantial.

This is why mobile users sometimes wake up to “channel force-closed.” Usually nobody is malicious — the LSP rebalanced or the node restarted with stale state. Your money is fine; you wait.

If you go offline long enough, a counterparty might try to publish an old state. Watchtowers are third-party services that monitor the chain on your behalf and broadcast the penalty transaction if they see cheating. Most casual users do not need them. Merchants and operators who go offline regularly often subscribe.

Practical advice

If you are new to Lightning:

1. Start with a custodial wallet (Wallet of Satoshi, Strike) to learn the UX.
2. Move to non-custodial mobile (Phoenix is my pick) for self-custody with sane defaults.
3. To participate fully, run your own node. Umbrel, Start9, and RaspiBlitz bundle Bitcoin Core plus Lightning on a Raspberry Pi.

Most important: do not store savings on Lightning. Channels are payment rails — for liquidity, not long-term storage. Keep your stack in cold storage; keep spending money on Lightning.

State of Lightning today

Real adoption is happening, just unevenly. Strike processes serious remittance volume into El Salvador and the Philippines. Nostr has Lightning zaps as its default tipping mechanism. Bitcoin podcasts split sats per minute to hosts via Podcasting 2.0.

The frontier is solving UX. Two protocols matter:

• BOLT12 offers — reusable payment requests that work like static QR codes, removing the awkward “generate-a-new-invoice-each-time” flow.
• Taproot Assets — issuing tokens (USD stablecoins included) on Bitcoin and routing them over Lightning. In early deployment in 2025–2026, this could open Lightning to non-BTC payments without abandoning the base layer.

Sources

• BOLT specifications — the protocol
• mempool.space lightning dashboard — public graph stats
• 1ML statistics — alternative graph view
• Amboss — node analytics and liquidity marketplace
• Lightning whitepaper, Poon-Dryja 2016 — original design
• Mastering Lightning — open-source deep reference

Lightning is not finished. Liquidity management is still hard for casual users. Routing reliability has improved but is not perfect. Dashboards undercount real activity. But it works, today, for what it claims — instant, cheap Bitcoin payments. Don’t trust me. Run a node and watch the sats move.