Timechain Wiki

The Lightning Network

11 min read

The Lightning Network is a peer-to-peer payment-channel network that settles to the Bitcoin base layer on channel-close, enabling near-instant low-fee Bitcoin-denominated payments at high frequency. Two parties open a channel by locking funds in a 2-of-2 multisig output and then exchange signed but unbroadcast commitment transactions that update channel state. Payments between parties without a direct channel route through intermediate hops using Hashed Timelock Contracts — atomic conditional payments that complete end-to-end or unwind cleanly — with source-side pathfinding from gossip-derived topology and onion routing for privacy. Specified by Joseph Poon and Thaddeus Dryja in 2015, Lightning became deployable after the 2017 SegWit malleability fix, and as of 2026 routes substantial daily volume across roughly 40,000 public channels and 4,000–5,000 BTC of public capacity. The network is operationally working but not friction-free — routing concentration, custodial-Lightning growth, channel-management complexity, and inbound-liquidity bootstrapping remain practical concerns. Subsequent notes treat Lightning channels, Lightning routing, and Watchtowers.

Why this note matters

Lightning is the dominant deployed Layer-2 system for Bitcoin and the medium-of-exchange infrastructure that the Bitcoin monetization framework rests on. The Monetization S-curve thesis — Bitcoin progresses from collectible to store of value to medium of exchange to unit of account — requires deployable medium-of-exchange infrastructure for Phase 3 transition; Lightning is that infrastructure. The base-layer is engineered for high-value settlement at slow tempo; Lightning is engineered for high-frequency low-value payments with explicit named tradeoffs.

This note serves as the overview reference. The internal architecture (channels, routing, monitoring) is treated in the dedicated notes that follow; this note establishes what Lightning is, what it does, and where it sits in the layered architecture.

What Lightning is

Lightning is not a separate blockchain. It is a network of Bitcoin transactions, most of which are never broadcast to the base-layer chain. The participants in a payment channel maintain a sequence of signed-but-unbroadcast transactions that represent the current state of their channel balance. Only the channel-open transaction (creating the multisig output) and the channel-close transaction (spending the multisig output back to participant addresses) appear on the base layer in the common case.

A payment-channel network. Two parties who have not opened a direct channel can still pay each other if a path of channels exists between them. The sender constructs a payment route through intermediate hops; each hop receives the payment from one neighbor and forwards it to the next under an atomic condition. If any hop fails, the entire payment unwinds cleanly; if every hop succeeds, the payment completes end-to-end.

The atomicity primitive — HTLCs. Each forwarded payment uses a Hashed Timelock Contract: the sender chooses a random secret, hashes it, and constructs an HTLC for each hop that pays out only if the hash-preimage (the secret) is revealed before a timeout. The receiver who knows the secret can claim their HTLC and reveal the preimage to their inbound neighbor; that neighbor uses the preimage to claim their inbound HTLC; the unwinding cascades back to the sender. If the receiver never claims, every HTLC times out and the funds return to the senders along the path.

The gossip-and-pathfinding layer. Channel announcements (after sufficient confirmations of the funding transaction) and channel-routing policy updates are published via a gossip protocol. Network participants can compute payment routes based on the gossip-derived topology. Routing is source-routed — the sender constructs the full hop sequence — with privacy preserved through onion routing (Sphinx routing).

Architectural layering

Lightning has its own internal layering distinct from the base-layer / Layer-2 distinction:

  • Channel layer. The 2-of-2 multisig output and the commitment-transaction sequence that defines a channel’s state between two parties. Treated in Lightning channels.
  • HTLC layer. The conditional-payment primitive that enables multi-hop atomic payments. Each commitment transaction includes the in-flight HTLCs as additional outputs.
  • Routing and gossip layer. The mechanism by which the network’s topology is published and payments are routed. Treated in Lightning routing.
  • Channel-monitoring layer. Online monitoring for force-close attempts; the watchtower model. Treated in Watchtowers.
  • Application layer. Wallets, Lightning Service Providers (LSPs), invoices (BOLT11 and BOLT12), keysend payments, splicing tools, and the operational tooling built on the underlying protocol.

This note treats the overview; the four dedicated notes treat the channel, routing, and monitoring layers; the application layer is referenced rather than treated at depth.

How a Lightning payment flows

A simplified example. Alice wants to pay Carol 0.001 BTC; they do not share a direct channel. The network gossip reveals that Alice has a channel with Bob, and Bob has a channel with Carol.

  1. Carol generates an invoice containing a random preimage’s hash, a payment amount, an expiry, and the route hints she wants to advertise.
  2. Alice’s wallet computes a route Alice → Bob → Carol from gossip-derived topology. Alice’s wallet constructs an onion-routed payment with HTLCs at each hop.
  3. Alice sends an HTLC to Bob for 0.001 BTC + Bob’s routing fee + cltv-buffer, locked by Carol’s preimage hash.
  4. Bob receives the HTLC, recognizes Carol as the next hop (from the onion’s encrypted hop data), and constructs his own HTLC to Carol for 0.001 BTC locked by the same preimage hash, with an earlier cltv-expiry than the HTLC he received.
  5. Carol receives Bob’s HTLC, sees that the preimage hash matches her invoice, and reveals the preimage to claim. Bob now has the preimage.
  6. Bob uses the preimage to claim Alice’s HTLC. The preimage propagates back to Alice as evidence of completion.
  7. Channel-state updates settle. Alice’s channel with Bob now shows Alice having 0.001+fee less; Bob’s channel with Carol shows Bob having 0.001 less and Carol having 0.001 more.

The payment is atomic. If Carol cannot claim within the timeout, every HTLC expires and the funds return to the senders. If Carol claims at any hop, the preimage cascades back and every hop claims correctly. There is no state in which Alice loses funds but Carol does not gain them, or vice versa.

Practical timing. Modern Lightning implementations complete typical payments in 1-5 seconds end-to-end across 2-5 hops. Pathfinding-failure retries can extend this; very-low-liquidity routes can fail multiple times before succeeding.

The current operational state of the network

As of 2026, Lightning’s deployed state is structurally as follows:

  • Public channel capacity is on the order of 4,000–5,000 BTC — down from a 2023 peak near 5,400 BTC — distributed across roughly 40,000 public channels. Public capacity, channel count, and node count have all plateaued and modestly declined from their 2021–2023 highs as the network consolidated toward fewer, better-capitalized routing nodes rather than growing organically; absolute levels fluctuate and public trackers disagree on them.
  • Private channels (channels not announced to the gossip layer) are estimated to be substantially larger than the public channel set but cannot be measured directly.
  • Custodial Lightning is a meaningful and growing share of end-user Lightning activity. Wallets-of-Satoshi-style services hold custodial Lightning balances and route payments on users’ behalf; this has been the dominant pattern for casual users.
  • Lightning Service Providers (LSPs) like Olympus, Voltage, and others have emerged to provide inbound-liquidity provisioning, just-in-time channels, and managed-node services for users who do not want to operate their own routing nodes.
  • Major implementations are LND (Lightning Labs), Core Lightning / CLN (Blockstream), Eclair (ACINQ), and LDK (Lightning Development Kit, primarily a library). Each implementation conforms to the BOLT specifications and interoperates with the others.

Use-case distribution. Empirical observation of Lightning usage suggests the dominant volume is in: cross-border value transfer (especially via El Salvador and African remittance corridors); content-creator zaps and value-for-value payments (Nostr-zap and podcasting 2.0); merchant-payment acceptance at small-and-medium-business scale; gaming and streaming applications.

Tradeoffs and design choices

Channel-network architecture vs broadcast-network architecture. Lightning’s design isolates each payment to a path-dependent set of channels rather than broadcasting state to all participants. The privacy and scaling consequences are significant: only participants on a payment path see anything about the payment, and the network can scale to arbitrary payment volume without each node processing every payment. The cost is that paths require pre-existing channel topology — there is no Lightning equivalent of “broadcast a payment to anyone with internet.”

Online requirements. Channel participants must be online to receive payments and to defend against malicious force-close attempts. This is structurally different from the base layer, where a payee can be offline and the payment is still credited on-chain. Watchtowers (see Watchtowers) outsource the defense against malicious force-close but require trust in the watchtower’s liveness.

Liquidity is bidirectional and pre-allocated. A channel has total capacity (the funding amount) divided between the two participants’ balances. To receive a payment, the recipient must have inbound liquidity — channel capacity sitting on the other side. New users routinely face the inbound-liquidity bootstrapping problem, addressed by LSP services that provide inbound liquidity for a fee.

Routing-concentration dynamics. Lightning’s gossip protocol and pathfinding favor nodes with many high-capacity channels — the well-connected hubs route more payments and earn more fees. This produces a hub-and-spoke topology over time, with substantive routing concentrating on a few hundred large nodes. The decentralization-vs-routing-efficiency tradeoff is intrinsic to the design and is the subject of substantive analytical critique; see Lightning Network operational critiques for the dedicated engagement.

Custodial-Lightning growth. Lightning’s UX complexity has driven a substantial share of end-user activity to custodial wallets. This is a Lightning-internal version of the broader Bitcoin self-custody-vs-custodial tradeoff; see Custody concentration risks for the analytical critique and Self-custody configuration ladder for the operational treatment. The Bitcoin maximalist position has internal disagreement about the legitimacy of custodial Lightning at scale.

Substantive analytical critique of Lightning’s deployment reality lives in Lightning Network operational critiques. The base-layer throughput question (which constrains Lightning’s channel-open-and-close capacity) is engaged in Network capacity and fee-market critiques.

Open questions for further development

  • How does Lightning evolve as the base-layer fee market sustains the network post-halving? Channel-management economics depend on base-layer fee dynamics. The post-2030 fee-revenue question (see Long-term security budget) interacts with Lightning’s channel-open-and-close fee structure.
  • What is the long-run equilibrium between custodial and self-sovereign Lightning? End-user adoption favors custodial; the maximalist disposition favors self-sovereign. The trajectory is unsettled.
  • Will protocol upgrades (PTLCs via Schnorr; eltoo via SIGHASH_NOINPUT or similar) be activated, and on what timeline? These would meaningfully improve Lightning’s privacy, watchtower-obviation, and channel-management properties.
  • How does the LSP ecosystem balance access vs centralization? LSPs make Lightning usable for casual users but introduce trusted-intermediary dependencies. The middle-ground architectures (self-custodial-with-LSP-assistance) are still evolving.
  • What is Lightning’s role relative to non-channel Layer-2 architectures (Ark, statechains, Fedimint)? Lightning is dominant now; competing architectures address different tradeoff profiles. The medium-term landscape may stratify by use-case rather than consolidate.

Canonical sources for this note

Foundational specification and reference

  • Mastering the Lightning Network (Antonopoulos, Osuntokun, Pickhardt; O’Reilly 2021) — the canonical Lightning technical reference
  • Joseph Poon and Thaddeus Dryja, “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments” (2015 white paper; revised 2016)
  • The BOLT specifications at github.com/lightning/bolts — BOLT01 through BOLT11 (and continuing) define the canonical protocol

Implementation references

  • LND documentation (Lightning Labs): lightning.engineering/api-docs
  • Core Lightning documentation (Blockstream): docs.corelightning.org
  • Eclair documentation (ACINQ): acinq.github.io/eclair
  • LDK documentation (Lightning Dev Kit): lightningdevkit.org

Adjacent references in this discussion

Graph View

Backlinks