Lightning Network Primer

The Lightning Network (LN) is a Layer 2 scaling solution for Bitcoin. Built "on top" of the blockchain, it enables near-instant transactions with extremely low fees.

It was proposed by Joseph Poon and Thaddeus Dryja in "The Bitcoin Lightning Network" whitepaper, first drafted in 2015, with the revision currently published dated January 2016.

Basic mechanism: Two parties open a "payment channel" (on-chain transaction) → conduct unlimited off-chain transactions within the channel → only the final balances are recorded on-chain when the channel closes.

This drastically reduces blockchain load. It does not, however, simply hand you Bitcoin's own security guarantees unchanged. Lightning's safety rests on being able to detect within a bounded time whether a counterparty has broadcast an old balance state, and on being able to get an on-chain transaction confirmed when you need one (that is, on fees not being prohibitive). The conditions under which those premises break are covered in "Revocation and Penalties" and "Challenges & Limitations."

Two parties open a payment channel by locking Bitcoin into a multisig address. This "funding transaction" is recorded on the blockchain.

After opening, both parties exchange "commitment transactions" to update balances. These happen off-chain (not recorded on the blockchain).

Example: If Alice wants to send Bob 10,000 satoshis, they create a new commitment transaction (Alice's balance -10,000, Bob's balance +10,000) and both sign it. This happens instantly.

When closing the channel, the latest commitment transaction is broadcast to the blockchain, finalizing each party's balance.

The Lightning Network's real power is that it can pay parties you have no direct channel with. Payments are routed through multiple channels.

HTLC (Hash Time-Locked Contract) technology eliminates the need to trust intermediate nodes. Payments are cryptographically secured with "hash locks": either the entire path succeeds at once, or everything fails.

Onion routing: Like the Tor network, each intermediate node only knows its immediate predecessor and successor. Privacy is not unconditional, though. The final hop knows who the recipient is, and the sender knows the entire route. Because the channel graph is public, probing (sending small trial payments) is a known technique for estimating channel balances. With a custodial wallet, the provider sees all of it anyway.

Routing fees are generally small, but "always under 1 satoshi" is not accurate. The default in widely used implementations is a base fee of 1 satoshi per hop plus a component proportional to the amount, so a multi-hop payment normally totals more than a satoshi. They remain orders of magnitude below on-chain fees, low enough that micropayments are economically viable.

HTLC (Hash Time-Locked Contract) is the core technology guaranteeing Lightning Network security.

Hash lock: The recipient can only claim funds by knowing a secret value (preimage). The hash of this value is shared in advance and used as the payment condition.

Time lock: If the preimage isn't presented within a set time, funds return to the sender. This prevents funds from being permanently locked if payment fails somewhere along the route.

What an HTLC guarantees is the hand-off of funds along a route. Preventing an old balance state from being used inside a channel is the job of a separate mechanism, covered next.

Every time the balance inside a channel is updated, both parties "revoke" the previous commitment transaction: each hands the other a key that invalidates the old state. This is a mechanism independent of HTLCs.

If a counterparty broadcasts an old commitment transaction (one more favorable to them), you can use the key you were given to build a "penalty transaction" and seize all the funds in the channel. The design makes cheating economically unattractive.

This defense does not operate automatically, however. To exercise the penalty you must detect the fraudulent broadcast within the relative timelock window. If your node stays offline until that window expires, the cheat simply stands.

Watchtowers exist to perform that monitoring on your behalf. Users who do not keep a node running continuously either use a watchtower or hand the job to a provider, which is the "custodial" category covered next.

There are broadly two ways to use Lightning. The difference is not one of convenience; it is a difference in what you lose when something breaks.

The claim that Lightning means "you do not have to trust intermediate nodes" describes the non-custodial case. In a custodial wallet, the balance on screen is not a channel balance in the protocol; it is a claim against the provider. If the provider fails, freezes accounts, or withdraws, the funds may not come back. Structurally this is the same as bitcoin left on an exchange: the category of failure documented in "Major Incidents & Lessons."

Intermediate arrangements also exist. An LSP (Lightning Service Provider) may supply liquidity and channel management while the user keeps the keys. Even then, the dividing line for trust is whether you can close the channel yourself and exit on-chain if the LSP walks away.

This site recommends no particular wallet. There is one question to start from: do you hold the private keys and a backup of the channel state? Wallet practice in general is covered in "Wallets & Security."

Micropayments: Sub-cent payments become possible. Content tipping, API billing, IoT device payments: use cases that were previously impossible have become real.

Instant settlement: Bitcoin payments at retail become as fast as credit cards. Lightning was used when El Salvador adopted bitcoin as legal tender in 2021, but a legal amendment in January 2025 made acceptance voluntary for the private sector and removed its legal tender status. Under the country's IMF agreement, the government has also stated it will end public-sector involvement in the Chivo wallet by selling or shutting it down. Where payments stand today is covered in "Paying with Bitcoin — The State of Payments."

Streaming payments: Per-second billing for music or video consumption is technically possible.

Cross-chain transactions: Atomic swaps between different blockchains can be executed via Lightning.

Public statistics from mempool.space show approximately 3,786 BTC of public channel capacity, 33,131 public channels, and 16,421 nodes as of August 16, 2026 (private channels are excluded; the true total including them is presumably higher but cannot be observed from outside). Channel count is down by half from a peak of roughly 80,000, which is generally explained as consolidation into larger channels plus the spread of LSPs (Lightning Service Providers). These figures move week to week, so do not read a single-date value as a trend.

Liquidity: Channels have capacity limits, and large payments may require split routing. Securing inbound capacity is also challenging.

Online requirement: Receiving payments requires the node to be online. Background monitoring on mobile wallets remains a challenge.

Channel management: Opening and closing require on-chain fees. High-fee periods reduce the economics of small channels.

Fraud monitoring: Detecting when counterparties broadcast old states requires periodic monitoring. Watchtower services mitigate this, though delegating the monitoring is itself a new trust assumption.

Route concentration: Public channel count has halved from a peak of roughly 80,000 to the low 30,000s, and capacity has concentrated into a small number of large nodes and LSPs. Routing through a big hub raises the odds a payment succeeds, but it also means the uptime, policies, and regulatory posture of specific businesses shape how usable the network is. When counting decentralization, the total number of nodes and the number of nodes actually used as routes are two different figures.

Drift back to custody: The simplest way to avoid all of the above (liquidity, the online requirement, monitoring) is to use a custodial wallet, and many users have done exactly that. Technical difficulty pulling users back toward the very intermediaries the design set out to remove is one of the themes covered in "Bitcoin Paradoxes."

These challenges are under active research and development, improving year over year. Of the items above, however, route concentration and the drift back to custody are not the kind that better technology alone resolves.

Taproot Assets (formerly Taro) is a protocol developed by Lightning Labs that allows digital assets such as stablecoins to be issued and transferred on Bitcoin's blockchain.

In March 2026, Tether officially launched USDT on the Lightning Network via Taproot Assets, enabling instant, low-fee USDT transfers as Lightning payments.

Taproot Assets is updated continuously, adding capabilities such as reusable addresses and auditable supply over successive releases. Version numbers change on short cycles, so check the developer's release notes for the current feature set.

Stablecoins on Lightning draw attention for cross-border remittances and for regions with unstable local currencies. What is being paid, however, is not bitcoin: issuer credit risk, redeemability, and regulatory standing have to be assessed separately from bitcoin itself.

In December 2025, public Lightning channel capacity reached an all-time high of 5,637 BTC. It then declined, standing at approximately 3,786 BTC as of August 16, 2026. Capacity does not simply grow in one direction. Figures for Lightning's "annual throughput" also circulate, but off-chain payment volume cannot be observed from outside, and no primary source identifies who produced those estimates or how, so this site does not adopt them.