How the Lightning Network Works

The Lightning Network is described in three different ways depending on who's talking: a Bitcoin payments solution, a Layer 2 scaling network, or a failed experiment with routing problems. The mechanism behind it is specific enough that none of these descriptions is quite accurate — and the distinctions matter for understanding what it can and can't do.

This post maps the mechanism: how payment channels work, how multi-hop routing connects them, and where the binding constraints sit.

The Core Problem Lightning Solves

Every Bitcoin transaction settles on the Bitcoin base layer. That settlement is final and irreversible, which is the whole point — but it comes at a cost. The network processes roughly 3–7 transactions per second at full capacity, and each transaction requires waiting for block confirmations before the recipient can treat it as settled.

For small, frequent payments — the kind that look like cash — this is structurally awkward. Bitcoin's fee market means that a $2 coffee payment competes with a $2 million treasury movement for block space. Lightning's answer is to move most transaction activity off-chain, settling only the net result on the Bitcoin base layer.

How Payment Channels Work

A payment channel is a two-party financial relationship secured by a Bitcoin multisig address on-chain.

The lifecycle has three phases:

Opening a channel: Both parties deposit bitcoin into a 2-of-2 multisig address via a funding transaction. This is the only on-chain step at opening. The funds are locked, and neither party can move them unilaterally — both signatures are required.

Transacting off-chain: Each time value changes hands, both parties exchange updated commitment transactions — pre-signed Bitcoin transactions representing the current balance split. These transactions are valid but not broadcast. They exist as enforceable claims, not settled facts. A channel can update hundreds of thousands of times without touching the blockchain.

Closing the channel: When either party wants to settle, they broadcast the latest commitment transaction. The Bitcoin base layer processes it, and each party receives their balance. From the blockchain's perspective, only two transactions ever occurred: the open and the close.

The security mechanism is the penalty clause. Each commitment transaction is time-locked, and each party holds a revocation key that can invalidate the counterparty's old states. If Alice tries to broadcast a previous commitment that favored her more, Bob can use the revocation key to claim all the funds in the channel. This makes broadcasting stale states economically irrational — the penalty is the entire channel balance.

How Multi-Hop Routing Works

Two-party channels are useful but limited. The Lightning Network extends them by routing payments through chains of intermediaries.

If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol without opening a direct channel — the payment routes through Bob's channel.

The mechanism that makes this safe is the Hash Time Locked Contract (HTLC). HTLCs are conditional payments: funds are locked with a cryptographic hash, and can only be claimed by providing the preimage (the value that hashes to that hash). They also carry a time lock — if the payment doesn't complete within a set window, it returns to the sender.

The flow for a multi-hop payment:

1. Carol generates a secret (the preimage) and gives Alice the hash of it.
2. Alice locks funds in an HTLC to Bob, conditional on the preimage being revealed.
3. Bob locks funds in an HTLC to Carol with the same condition.
4. Carol reveals the preimage to claim Bob's payment.
5. Bob uses the revealed preimage to claim Alice's payment.

Each hop settles atomically — either the entire route completes or nothing moves. No intermediate party can steal funds. The preimage propagates backward through the chain once Carol claims.

Where Constraints Live

Liquidity: Payment channels have finite capacity. A channel can only forward as much as is locked in it on the relevant side. If Alice wants to send 0.1 BTC to Carol through Bob, Bob needs at least 0.1 BTC of outbound capacity toward Carol. This creates real routing failures on larger or unusual payment paths. The network is not a single pool of liquidity — it's a graph of bilateral balances, and routing depends on the specific topology at that moment.

Routing reliability: Finding a path that has sufficient liquidity at every hop is a pathfinding problem that gets harder as network topology fragments. Payments fail silently — the sender retries via alternative paths or the payment doesn't go through. Large payments fail more often than small ones; this is not a bug but a structural property of the model.

Online requirement: A Lightning node must be online to receive payments. An offline node cannot update channel state. Watchtower services address the penalty monitoring problem (ensuring old states aren't broadcast while you're offline), but they add operational complexity.

Base layer dependency: Opening and closing channels requires Bitcoin transactions. During high base-layer fee periods, channel management becomes expensive relative to payment size — which affects the economics of maintaining many small channels.

What's Changing

Two structural developments are worth tracking.

Taproot and PTLCs: The Lightning Network currently uses HTLCs, which are visible on-chain as distinct script patterns. Point Time Locked Contracts (PTLCs) replace the hash-based lock with a Schnorr signature scheme enabled by Bitcoin's Taproot upgrade (activated November 2021). PTLCs improve privacy (removing the correlation of HTLCs across hops) and reduce on-chain footprint. Migration from HTLCs to PTLCs requires network-wide implementation — it's in progress but not complete as of early 2026.

Splicing: Splicing allows channel capacity to be adjusted without closing and reopening the channel. A splice-in adds bitcoin; a splice-out removes it. This addresses one of the main operational friction points — currently, resizing a channel requires an on-chain close and open. Splicing support has been shipping incrementally across major Lightning implementations.

What Would Confirm Progress

Routing success rates increasing toward 99% on payments under 0.01 BTC. PTLC implementation across major node software (LND, CLN, Eclair). Splice support reaching the majority of public nodes. Growth in routing node count without corresponding deterioration in payment success rates.

What Would Break or Invalidate It

A discovered exploit in HTLC atomicity that allows intermediate node theft. A base layer fee environment so elevated that channel economics become unworkable for small payments. A competing mechanism (e.g., Ark, channel factories, or a non-custodial off-chain alternative) achieving better UX and reliability at scale, redirecting developer attention and capital. Or simply continued routing failure rates making Lightning unreliable as a payment layer.

Timing Perspective

Now: Lightning is operational and used — but routing reliability and liquidity management remain friction points for non-custodial participants. Custodial Lightning wallets sidestep these constraints at the cost of self-custody.

Next: PTLC migration and widespread splice support are the mechanisms that move Lightning from functional to practical at scale. These are in active development.

Later: Higher-order constructions — channel factories, Ark — that would extend Lightning's model to larger user populations without linear growth in on-chain footprint. Still research-stage.

Boundary Statement

This post explains the mechanism of the Lightning Network as designed and currently implemented. It does not assess Lightning's prospects relative to other payment approaches, nor does it constitute a recommendation about how or whether to use it. The constraints described are structural, not temporary — any realistic evaluation of Lightning as a payment layer needs to account for them. The static explanation ends here. The tracked version lives elsewhere.