The Lightning Network: Bitcoin layer 2 explained

Bitcoin has a scaling problem known since its origins. The blockchain×BlockchainA public, shared ledger that records every Bitcoin transaction in blocks linked together cryptographically. Each participant in the network keeps a copy.See in the lexicon → processes about 7 transactions per second in normal operation, while Visa peaks at 1 700. During activity spikes, fees rise, transactions pile up in the mempool×MempoolWaiting area where Bitcoin transactions sit before being included in a block. The fuller the mempool, the higher the fees required.See in the lexicon →, and paying for a 4 EUR coffee can cost 8 EUR in fees.

This tension split the community in 2017 : enlarge the block size, or build a layer above that scales differently ? The historical answer was the second, with Lightning Network×Lightning NetworkSecond-layer payment network on top of Bitcoin. Enables near-instant and near-free payments through channels opened between users.See in the lexicon →. The idea : open a payment channel between two parties, exchange×ExchangeService that lets you buy, sell and swap cryptocurrencies against fiat money. Examples : Kraken, Coinbase, Bitstamp, Bitvavo. Most are custodial.See in the lexicon → sats off-chain as much as wanted, and touch the blockchain only when closing the channel. Near-zero fees, instant finality, capacity bounded only by the funds locked in channels.

This article explains the theoretical frame of Lightning, the mechanics of channels and routing, the difference between custodial×CustodialModel in which a third party (exchange, broker, neobank) holds your private keys for you. You have a claim, not a bitcoin. « Not your keys, not your coins ».See in the lexicon → and non-custodial×Non-custodialCommon synonym for self-custody in marketing communications.See in the lexicon → nodes, the choice of a suitable wallet×WalletSoftware or device that manages your Bitcoin keys and lets you sign transactions. A wallet does not really « hold » your bitcoins, it holds the keys that prove you own them.See in the lexicon → (Phoenix, Muun, Aqua, Wallet of Satoshi×Satoshi (sat)The smallest unit of bitcoin. 1 BTC = 100 million satoshis. Named after the creator. In 2026, talking in sats becomes common as the price of one BTC rises.See in the lexicon →), and the residual limits (inbound liquidity×Inbound liquidityCapacity of a Lightning channel to receive payments. To get paid 100,000 sats, you need at least 100,000 sats of inbound liquidity available.See in the lexicon →, forced closes, watchtowers, limited privacy).

The problem: Bitcoin does not scale as-is

To understand Lightning, you must grasp the structural constraints of Bitcoin on-chain.

• One block every 10 minutes. The Bitcoin protocol tunes difficulty so a block is mined on average every 10 minutes. Non-negotiable: it is encoded in consensus. Each block carries at most ~1 MB of useful transactions (a bit more with SegWit×SegWit (Segregated Witness)Upgrade activated in 2017 that separates signature data from the rest of the transaction. Lowered fees and paved the way for Lightning Network.See in the lexicon →, but the order of magnitude holds). Mechanically this gives a capacity of about 7 transactions per second on a long-term average.
• Queues when activity exceeds 7 TPS. During peaks (bull rally, geopolitical event, Ordinals×Ordinals (inscriptions)Protocol (2023) that numbers each satoshi and allows inscribing data (images, text) directly on-chain via Tapscript. At the origin of the debate on block space usage.See in the lexicon → inscription rush), 20 or 50 TPS hit the mempool×MempoolWaiting area where Bitcoin transactions sit before being included in a block. The fuller the mempool, the higher the fees required.See in the lexicon →, which does not drain fast enough. Miners prioritise transactions paying the most fees, others wait. Fees that reached 100 EUR per transaction during 2021-2024 peaks, back down to 1-10 EUR in 2026 outside peaks, but structurally unbounded.
• Cannot scale by increasing block size without tradeoff. Doubling block size doubles TPS capacity, but also doubles the disk and bandwidth required to run a node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon →. At some threshold, only data centres can run a node, and Bitcoin centralises. That red line crystallised the community in 2017.

The conceptual solution has two key properties.

• Move daily payments off-chain. To pay a coffee, you do not touch the blockchain×BlockchainA public, shared ledger that records every Bitcoin transaction in blocks linked together cryptographically. Each participant in the network keeps a copy.See in the lexicon →. The transaction happens on a layer above, capable of millions of TPS. The blockchain serves as a cryptographic safety net: if layer 2 malfunctions, you can always fall back to the blockchain to recover funds.
• Keep Bitcoin as cryptographic collateral. No new token, no pre-mine, no altcoin×Altcoin (shitcoin, memecoin)Any cryptocurrency other than Bitcoin (Ethereum, Solana, etc.). The pejorative terms shitcoin and memecoin refer to projects with no real utility or purely speculative ones.See in the lexicon →. Bitcoin on Lightning is 100 % backed by on-chain bitcoins. Opening a channel locks bitcoins on the blockchain, closing releases them. Layer 2 mints nothing, it just shifts the timing of settlements.

Concretely, what it enables in 2026.

• Near-unlimited capacity per node pair. Two people with a channel between them can exchange×ExchangeService that lets you buy, sell and swap cryptocurrencies against fiat money. Examples : Kraken, Coinbase, Bitstamp, Bitvavo. Most are custodial.See in the lexicon → millions of payments in hours, at near-zero fees and 2-second finality.
• Fees decoupled from amount. Paying 10 EUR or 1,000 EUR costs the same ~0.001 EUR Lightning fees, where an on-chain transaction also charges similarly regardless of amount, but far more in absolute terms.
• No more mempool for daily payments. The blockchain only sees channel openings and closings, not every intermediate payment. Huge relief on the blockchain itself.

The tradeoff: this is not Bitcoin on-chain. It looks like Bitcoin, it is collateralised by Bitcoin, but the security model, risks and operations differ. That is what follows next.

The payment channel: the elementary brick

Lightning is not an abstract network. It is a set of payment channels between node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → pairs. Understanding one channel is enough to understand Lightning.

Picture two people, Alice and Bob, who will exchange×ExchangeService that lets you buy, sell and swap cryptocurrencies against fiat money. Examples : Kraken, Coinbase, Bitstamp, Bitvavo. Most are custodial.See in the lexicon → payments regularly. Rather than writing every exchange on the blockchain×BlockchainA public, shared ledger that records every Bitcoin transaction in blocks linked together cryptographically. Each participant in the network keeps a copy.See in the lexicon → (10 minutes, 3 EUR fees each time), they open a channel between themselves. The channel lives in four phases.

1. Funding transaction. Alice and Bob together craft an on-chain transaction that locks bitcoins in a 2-of-2 multisig×Multisig (multi-signature)Configuration where a transaction must be signed by several independent keys to be valid (for example 2 of 3). Reduces the risk that a single key theft causes loss of funds.See in the lexicon → UTXO×UTXO (Unspent Transaction Output)« Chunk » of bitcoin received and not yet spent. A wallet does not have a single balance, it has a collection of UTXOs whose sum makes up the balance.See in the lexicon → controlled by both. Say Alice puts 500,000 sats, Bob puts 500,000 sats, total 1,000,000 sats locked. This transaction is broadcast on the blockchain, awaits 3 to 6 confirmations, and the channel is officially open. This is the only on-chain transaction at opening.
2. Commitment transactions. During the channel's life, for every payment, Alice and Bob exchange commitments. A commitment is a new transaction signed but not broadcast spending the funding transaction. It says "if we close now, Alice gets X and Bob gets Y". On every payment, they swap a new commitment reflecting the new balance. If Alice pays 50,000 sats to Bob, the new commitment says "Alice 450,000, Bob 550,000". None of these commitments touch the blockchain: they stay in both nodes' memories.
3. Permanent update. On the next payment (Bob returns 10,000 sats to Alice), a new commitment says "Alice 460,000, Bob 540,000". And so on, millions of times if needed. The revocation mechanic ensures the old commitment can no longer be broadcast: if Alice tries to broadcast an old commitment favourable to her, Bob can "punish" by claiming all channel funds. That is what makes off-chain updating safe.
4. Closing transaction. When Alice and Bob want to close the channel (or one wants their funds back), one of them broadcasts the latest signed commitment on the blockchain. The blockchain confirms the transaction, the 2-of-2 multisig bitcoins are released per the latest balance. A cooperative close (both agree) takes 1 transaction. A forced close (one only, because the other is offline) takes longer with a safety delay (typically 144 blocks, ~24 h) to allow detecting a fraud attempt.

Three key properties of this mechanic to remember.

• Only 2 on-chain transactions. Opening + closing. In between, millions of payments are possible for the cost of 2 on-chain transactions. That is the scalability gain.
• No trust required. Alice and Bob do not trust each other. The cryptographic mechanic (2-of-2 multisig, revocation) ensures neither can cheat. If Alice tries to walk off with everything by broadcasting an old commitment, Bob has 144 blocks to react and punish.
• Capacity bounded by funding. The Alice-Bob channel with 1 million locked sats allows exchanging at most 1 million sats in one direction. If Alice already sent everything to Bob, the channel is "exhausted" on Alice's side and she can no longer send without rebalancing×RebalancingRebalancing your portfolio by selling part of what has risen and buying what has fallen, to return to a target allocation.See in the lexicon → or reopening.

The Alice-Bob channel works well if Alice and Bob exchange often. But you will not open a channel with every merchant you meet. That is where node-to-node routing comes in.

Hop routing: paying without a direct channel

If Alice has to open a direct channel with every counterparty (the baker, the restaurant, the Brazilian freelance, the Patreon server), she opens 50 channels a month, pays 150 EUR in on-chain fees, and the system collapses. The genius of Lightning is that payments route through the existing network.

Picture this scenario. Alice has a channel with Carol. Carol has a channel with Dave. Dave has a channel with Bob, to whom Alice wants to pay 50,000 sats. Alice and Bob have no direct channel, but the path Alice → Carol → Dave → Bob exists. Lightning routes the payment through that path in seconds.

Mechanically, the multi-hop payment goes like this.

1. Path discovery. Alice's wallet×WalletSoftware or device that manages your Bitcoin keys and lets you sign transactions. A wallet does not really « hold » your bitcoins, it holds the keys that prove you own them.See in the lexicon → (or her LSP×LSP (Lightning Service Provider)Third-party service that helps open Lightning channels and manage liquidity, without holding your funds. Used by mobile wallets like Phoenix.See in the lexicon →) queries the public Lightning network×Lightning NetworkSecond-layer payment network on top of Bitcoin. Enables near-instant and near-free payments through channels opened between users.See in the lexicon → topology (graph of all known channels and nodes, updated via the "gossip protocol" propagating channel announcements). It computes a path between her node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → and Bob's with enough liquidity in the right direction.
2. Payment construction. Alice pays Carol 50,000 sats + a small fee. Carol pays Dave 50,000 sats + a small fee (slightly less). Dave pays Bob exactly 50,000 sats. At each hop, the intermediary node keeps a fraction (typically 0.01 to 1 sat per payment) as compensation for routing.
3. Atomicity via HTLC×HTLC (Hashed Time Lock Contract)Contract locked by hash and by time, the building block of Lightning payments: it guarantees that a multi-hop payment is either delivered in full or refunded.See in the lexicon → (next section). Either the whole path succeeds and every commitment is updated, or nothing happens and each keeps what they had. No intermediate scenario where Carol keeps Alice's funds without transferring to Dave.
4. Confirmation. Bob's wallet notifies Alice via the reverse path that payment is received. Total: 2 to 5 seconds for 3 hops. Cumulative typical fees: 0.001 to 0.01 EUR.

The "gossip protocol" maintaining the public topology is a key point. All public Lightning nodes announce their open channels (total capacity, fees, policy). Those announcements propagate between nodes. In 2026, any Lightning wallet has a full view of the graph: ~18,000 public nodes, ~85,000 channels, updated almost in real time.

Three practical questions this raises.

• How many hops on average? In 2026, the network is dense enough that 3 to 5 hops suffice in the vast majority of cases. Beyond, routing failure probability grows, and wallets search alternative paths.
• How is privacy guaranteed? Intermediary nodes only know the previous and next hop, not the origin nor destination of the payment. That is the onion-routing principle (similar to Tor). Carol knows Alice sends her 50,000 sats to forward, but does not know it is for Bob.
• What if a hop is offline? If Dave is offline at payment time, routing fails after a short timeout (typically 30 seconds). Alice's wallet tries another path if available. If no path is found, the payment is cancelled, funds stay with Alice. No loss.

HTLC: the atomic payment guarantee

Hop routing raises an obvious question: when Alice pays Carol to forward to Dave who pays Bob, how to be sure Carol does not keep the money without forwarding? And how to be sure Dave does not do the same? The answer is a cryptographic mechanism called HTLC×HTLC (Hashed Time Lock Contract)Contract locked by hash and by time, the building block of Lightning payments: it guarantees that a multi-hop payment is either delivered in full or refunded.See in the lexicon →: Hash×HashFunction that turns data of any size into a fixed-size fingerprint. The same input always yields the same output, but you cannot go back from output to input.See in the lexicon → Time-Locked Contract.

The principle in two phases.

1. Locking phase. Bob (the final recipient) secretly generates a random value R, and computes its hash H = SHA256(R). He sends H to Alice via a separate channel (e.g. inside the BOLT11×BOLT11Standard format for a Lightning invoice, as a character string or QR code. An invoice is single-use, with an amount and an expiry date.See in the lexicon → invoice). Alice builds an HTLC telling Carol: "here are 50,050 sats, you can claim them by revealing an R such that SHA256(R) = H". Carol does the same with Dave: "here are 50,010 sats, you can claim them by revealing an R such that SHA256(R) = H". Dave does the same with Bob: "here are 50,000 sats, you can claim them by revealing an R...".
2. Reveal phase. Bob, who knows R (he generated it), reveals it to Dave to claim his 50,000 sats. Dave now has R, which lets him claim his 50,010 sats from Carol. Carol reveals R to Alice to claim her 50,050 sats. And so the payment cascades atomically back up the chain: either the full cascade happens, or nothing.

And if Bob does not reveal R? That is where the "Time-Locked" part of HTLC comes in. Every HTLC has an expiration. If R is not revealed before expiration, the HTLC unwinds and each party gets their funds back. Alice loses nothing if Carol, Dave or Bob is offline or hostile.

Three crucial properties this mechanic guarantees.

• Full atomicity. Either all intermediary nodes received their fees, or none did. It is mathematically impossible for Carol to keep 50,050 sats without Dave getting 50,010, because Carol can only claim her funds by revealing R, which she can only do if Dave received and revealed R downstream.
• No intermediate theft risk. No intermediary node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → can "keep" the funds passing through. The cryptographic lock is hash H, and only Bob the recipient knows the preimage R. Carol and Dave earn their fee if they honestly participate in routing, and nothing otherwise.
• Graceful failure. If Bob is offline or refuses to reveal R, the HTLC expires (typically after 144 blocks, ~24 h), funds return to each sender, and Alice can retry another path. No hard loss.

Inbound and outbound liquidity, and LSPs

A counter-intuitive specificity of Lightning: a channel's liquidity is not symmetric. Understanding that asymmetry avoids the classic "I have 100,000 sats in Phoenix but I cannot receive anything" mistake.

Take back the Alice-Bob channel opened with 1 million sats. If Alice funded it all (1,000,000 sats on her side, 0 on Bob's), then:

• Alice can send up to 1,000,000 sats to Bob (her outbound liquidity).
• Alice can receive nothing from Bob, because there are no sats on Bob's side to slide back to her (her inbound liquidity×Inbound liquidityCapacity of a Lightning channel to receive payments. To get paid 100,000 sats, you need at least 100,000 sats of inbound liquidity available.See in the lexicon → is zero).

As Alice sends to Bob, her side balance shrinks and Bob's grows. If Alice sent 600,000 sats, the channel is now 400,000 / 600,000. Alice can still send 400,000 sats, and she can now receive up to 600,000 sats from Bob. Liquidity is dynamic: it rebalances with usage.

Three practical problems this asymmetry creates for a normal user.

• Receiving a first payment. If you install Phoenix and have no channel, you can receive nothing. You need a channel with inbound liquidity first. Phoenix solves that automatically by opening a channel for you on the first received payment (the LSP×LSP (Lightning Service Provider)Third-party service that helps open Lightning channels and manage liquidity, without holding your funds. Used by mobile wallets like Phoenix.See in the lexicon → injects the liquidity). Before Phoenix, that was a major friction for beginners.
• Receiving a large payment. If you have a 200,000-sat inbound capacity channel and someone wants to send you 500,000 sats, the payment fails. Solution: Phoenix dynamically opens a bigger channel, or asks your LSP to splice (extend) the existing channel. One-off on-chain fee cost.
• Sending after receiving everything. If you accumulated 800,000 sats on Lightning and want to send them all out, you risk partial routing failure due to available channel capacity. Solution: send in parts, or wait for the wallet×WalletSoftware or device that manages your Bitcoin keys and lets you sign transactions. A wallet does not really « hold » your bitcoins, it holds the keys that prove you own them.See in the lexicon → to rebalance via on-chain swap.

For consumer users, the solution to all these complexities is the LSP (Lightning Service Provider). An LSP is a well-connected Lightning node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → that manages liquidity, routing and channel openings on your behalf. Three common 2026 models.

Phoenix dominates the consumer market in 2026 thanks to its balance: transparent embedded LSP, self-custody×Self-custodyModel in which you hold your own private keys. Your bitcoins depend on no third party. This is Bitcoin's founding promise.See in the lexicon → wallet (keys stay on the device), automatic channel opening, on-the-fly splice, seed-phrase restore. For 95 % of users, it is the right default. For advanced users wanting to control their channels, the personal node remains the sovereign path (cf. Bitcoin node article).

2026 network state, comparison and limits

A few figures to situate Lightning in 2026.

• ~18,000 public nodes, against ~16,000 in 2023 and ~12,000 in 2021. Slow but steady growth. On top, an unknown number of private nodes (typically Phoenix / Aqua user nodes that do not announce in gossip).
• ~85,000 open channels, ~4.7 channels per public node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → on average. About a dozen major nodes (ACINQ, Bitfinex, Wallet×WalletSoftware or device that manages your Bitcoin keys and lets you sign transactions. A wallet does not really « hold » your bitcoins, it holds the keys that prove you own them.See in the lexicon → of Satoshi×Satoshi (sat)The smallest unit of bitcoin. 1 BTC = 100 million satoshis. Named after the creator. In 2026, talking in sats becomes common as the price of one BTC rises.See in the lexicon →, Kraken) concentrate a large share of liquidity.
• ~6,000 BTC total capacity (~250 million EUR at 2026 rate), against ~5,200 BTC in 2023. Growth correlated with merchant adoption.
• Median channel: ~2 million sats (~600 EUR), with a long tail: some channels exceed 100 million sats (30,000 EUR) for enterprise nodes, many sit around 500,000 sats for individual users.

Practical differences table on-chain vs Lightning, useful to decide on each payment.

Six current Lightning limits to know in 2026 for realistic expectations.

• Per-payment caps. The network handles well payments up to ~5 million sats (~1,500 EUR) in one shot. Beyond, routing failure probability rises, and one must split the payment (Multi-Part Payments, MPP×MPP (Multi-Path Payment)Lightning payment split across several simultaneous paths, recombined on arrival. Allows paying amounts larger than the capacity of a single channel.See in the lexicon →) or fall back on-chain.
• Uneven liquidity. Some heavily-demanded nodes (large exchange×ExchangeService that lets you buy, sell and swap cryptocurrencies against fiat money. Examples : Kraken, Coinbase, Bitstamp, Bitvavo. Most are custodial.See in the lexicon → nodes) have channels full in one direction and can no longer route that way. Wallets use retry, but it slows down.
• Forced close. If your LSP is down, your wallet may be forced to close its channels on-chain (forced close), with extra on-chain fees and a 24 h delay. Phoenix handles that automatically but the fee remains yours.
• Mandatory SCB×SCB (Static Channel Backup)Static backup of Lightning channels (LND). If the node crashes, it allows requesting the cooperative closing of channels and recovering the funds.See in the lexicon →. Static Channel Backup. Without periodically backing up your channels' state, losing your phone means losing Lightning funds (the seed phrase×Seed phraseSequence of 12 or 24 words (usually in English) that encodes your master key. Universal wallet backup : with these words, you can restore your funds on any compatible software.See in the lexicon → is not enough for Lightning, unlike on-chain). Phoenix backs up automatically to encrypted iCloud / Google Drive, but check it.
• Online dependency. Commitments must stay up to date, requiring your wallet to be online at least intermittently. A phone lost for 6 months can lead to forced closes by the LSP, with on-chain fees.
• Imperfect privacy. Onion routing protects the destination from intermediaries well, but statistical analysis attacks (probing) can identify repeated payments between two nodes. Lightning is not Monero.