How the Lightning Network Works

The Lightning Network is a payment channel network built on top of Bitcoin that enables near-instant, low-fee transactions between participants without recording every payment on the blockchain. It works by letting two parties lock funds into a shared on-chain transaction, then exchange an unlimited number of off-chain payments between themselves by updating cryptographic commitments. When they are done, they settle the final balance back to the blockchain in a single transaction. This is the core idea behind Layer 2 scaling: move the high-frequency activity off-chain while relying on Layer 1 only for dispute resolution and final settlement.

If you are familiar with how Bitcoin's base layer works -- miners, blocks, UTXO-based transactions -- the Lightning Network sits directly on top of that infrastructure. It does not require a separate blockchain or token. Every Lightning channel is ultimately backed by a real Bitcoin transaction that can be broadcast and confirmed by the same network of nodes and miners that process all other Bitcoin transactions.

Payment Channels: The Foundation

A payment channel is a two-party arrangement that allows Alice and Bob to transact with each other off-chain. The lifecycle of a channel has three phases: funding, updating, and closing.

The Funding Transaction

To open a channel, Alice and Bob cooperate to create a funding transaction -- an on-chain Bitcoin transaction that sends coins into a 2-of-2 multisignature output. This means neither party can spend the locked funds unilaterally; both signatures are required. The funding transaction is broadcast to the Bitcoin network and must be confirmed in a block before the channel is considered open.

For example, Alice might contribute 0.05 BTC and Bob might contribute 0.05 BTC, creating a channel with a total capacity of 0.1 BTC. The initial balance is 0.05 each. From this point forward, they can shift that balance back and forth without touching the blockchain.

Commitment Transactions

The current balance of the channel is encoded in commitment transactions -- pre-signed Bitcoin transactions that spend the funding output and distribute the funds according to the latest agreed-upon split. Each party holds their own version of the commitment transaction, asymmetrically constructed so that broadcasting your own commitment gives your counterparty an advantage (a time-locked revocation path) while broadcasting the other party's does not.

When Alice pays Bob 0.01 BTC, they construct a new pair of commitment transactions reflecting the updated balance (Alice: 0.04, Bob: 0.06). Crucially, they also exchange revocation keys for the old commitment transactions. If Alice were to broadcast the old state (where she had 0.05), Bob could use the revocation key to claim all the funds in the channel as a penalty. This revocation mechanism is what makes it safe to transact off-chain: cheating is economically irrational because it costs you everything.

Closing the Channel

A channel can be closed in three ways:

• Cooperative close -- Both parties agree on the final balance and sign a single closing transaction. This is the cleanest path: no time locks, minimal fees, immediate finality.
• Unilateral close -- One party broadcasts their latest commitment transaction without the other's cooperation. The broadcasting party's funds are time-locked (typically 144 blocks, or about a day), giving the counterparty a window to contest with a revocation key if the broadcast state was outdated.
• Penalty close -- If one party broadcasts a revoked (outdated) commitment transaction, the other party can use the revocation key to claim the entire channel balance. This is the enforcement mechanism that keeps the system honest.

HTLCs: Conditional Payments

Direct payment channels between two parties are useful but limited. The real power of Lightning comes from Hash Time-Locked Contracts (HTLCs), which enable payments to be routed through intermediaries who do not need to trust each other.

An HTLC is a conditional payment: "I will pay you X if you can present the preimage of hash H within T blocks, otherwise I get my money back." It works like this:

1. The recipient (Carol) generates a random secret S and computes H = SHA256(S). She sends H to the sender (Alice).
2. Alice creates an HTLC in her channel with Bob: "Pay Bob 0.01 BTC if he reveals the preimage of H within 100 blocks."
3. Bob, who has a channel with Carol, creates a similar HTLC with Carol: "Pay Carol 0.01 BTC if she reveals the preimage of H within 50 blocks." (The timeout is shorter to give Bob time to claim from Alice.)
4. Carol knows S, so she reveals it to Bob and claims her payment.
5. Bob now knows S, so he reveals it to Alice and claims his payment.

The payment atomically settled across two hops. Either the entire chain resolves (Carol gets paid, Bob gets reimbursed, Alice's payment goes through) or none of it does (timeouts expire, funds return to senders). There is no state where Bob is out of pocket.

Multi-Hop Routing and Onion Encryption

Real Lightning payments typically traverse more than two hops. The sender must find a path through the network -- a sequence of channels with sufficient capacity -- and construct the payment instructions for each hop. Lightning uses source routing: the sender determines the entire path upfront, rather than having each intermediate node decide where to forward the payment.

To preserve privacy, Lightning encrypts the routing information using onion routing, a technique shared with Tor. The sender wraps the payment instructions in layers of encryption, one for each hop. Each intermediate node can only decrypt its own layer, which reveals:

• The next hop to forward to
• The amount and HTLC parameters for the next hop
• An encrypted blob to pass to the next node

An intermediate node cannot determine the sender, the recipient, or the total path length. It only knows its immediate predecessor and successor. This is structurally identical to how Tor's onion routing protects the identity of web users, adapted for payment forwarding instead of IP packet forwarding.

The onion packet format used by Lightning is called Sphinx, based on a 2009 academic paper by George Danezis and Ian Goldberg. Sphinx provides unlinkability (no observer can correlate incoming and outgoing payments at a node based on the encrypted payloads alone) and uses a fixed packet size to prevent length-based correlation attacks.

Channel Capacity and Liquidity

Every Lightning channel has a fixed capacity -- the total amount of Bitcoin locked in the funding transaction. This capacity does not change during the channel's lifetime (unless splicing is used, discussed below). What changes is the balance split: how much of the capacity is on Alice's side versus Bob's side.

This creates an important and often misunderstood constraint: liquidity is directional. If Alice has a channel with Bob where Alice holds 0.08 BTC and Bob holds 0.02 BTC, Alice can send Bob up to 0.08 BTC, but Bob can only send Alice up to 0.02 BTC. The channel has 0.08 BTC of outbound liquidity from Alice's perspective and 0.02 BTC of inbound liquidity.

For routing, every channel on the path must have sufficient liquidity in the right direction. A payment from Alice to Carol through Bob requires:

• Alice's channel with Bob to have enough outbound liquidity (Alice-side balance)
• Bob's channel with Carol to have enough outbound liquidity (Bob-side balance)

This directional liquidity constraint is the single largest practical challenge for Lightning routing. A channel can have 1 BTC of total capacity but zero usable liquidity in one direction. External observers can see channel capacity (it is derived from the on-chain funding transaction) but cannot see the balance split -- that is private information known only to the two channel partners.

Pathfinding Algorithms

Finding a viable path through the Lightning Network is a graph-search problem with unusual constraints. Unlike BGP routing, where the goal is to find a path to a destination prefix and the link capacities are generally large enough that routing decisions are based on policy rather than capacity, Lightning pathfinding must account for the directional liquidity of each channel on the path.

Lightning implementations typically use modified versions of Dijkstra's algorithm, optimizing for a combination of:

• Fees -- Each routing node charges a base fee plus a proportional fee (e.g., 1 sat + 0.01%). The pathfinding algorithm minimizes total fees.
• Probability of success -- Since balance distributions are unknown, the algorithm estimates the probability that each channel has sufficient liquidity. Larger payments through smaller channels are less likely to succeed.
• CLTV delta -- Each hop requires a time-lock difference (CheckLockTimeVerify delta) for HTLC safety. Longer paths accumulate larger total time locks, locking up funds for longer in the failure case.

The most widely used pathfinding approach today is a probabilistic model that assumes channel balances follow a uniform distribution between 0 and capacity. Given a channel with capacity C and a payment of amount A, the probability of success is estimated as (C - A + 1) / (C + 1). The pathfinding algorithm then maximizes the product of success probabilities across all hops (equivalent to minimizing the sum of negative log probabilities), weighted against fees.

When a payment fails because an intermediate channel lacks liquidity, the sender receives an encrypted error that identifies the failing channel. The pathfinding algorithm then excludes that channel and tries an alternative route. This iterative "try and learn" approach converges quickly for small payments but can struggle for large ones, which is why multi-part payments (MPP) were introduced: splitting a single payment across multiple smaller paths that are reassembled at the destination.

Watchtowers

The security of Lightning channels depends on both parties monitoring the blockchain. If Alice broadcasts a revoked commitment transaction while Bob is offline, the revocation time lock will expire and Alice will steal funds. This is a real threat for mobile wallets and users who are not always online.

Watchtowers solve this by acting as a delegated monitoring service. Bob gives a watchtower a compact blob of data for each revoked state -- just enough to construct a penalty transaction if the revoked commitment appears on-chain. The watchtower monitors the blockchain continuously and, if it detects a breach, broadcasts the penalty transaction on Bob's behalf.

Watchtower designs balance privacy and efficiency:

• Storage -- A watchtower needs to store a small record for each revoked state. For a channel with thousands of state updates, this is a few megabytes at most.
• Privacy -- The watchtower only sees a transaction ID to watch for and an encrypted penalty blob. It cannot determine channel balances, counterparty identities, or payment details unless a breach actually occurs.
• Incentives -- Watchtowers can be altruistic (run by the community), paid per update, or rewarded with a fraction of the penalty if they successfully defend a breach.

Channel Factories

One limitation of Lightning is that every channel still requires an on-chain funding transaction. If millions of users each want multiple channels, the blockchain cannot sustain the transaction volume for opening and closing. Channel factories are a proposed construction that amortizes the on-chain cost across many channels.

In a channel factory, a group of N participants (say, 10) create a single on-chain transaction that funds a shared UTXO. From this shared output, they can create and close channels among themselves off-chain, only touching the blockchain for the initial group funding and the final settlement. A channel factory with 10 participants can create 45 pairwise channels from a single on-chain transaction, reducing the per-channel footprint by an order of magnitude.

Channel factories require all participants to cooperate for reconfiguration (adding or removing channels within the factory), which introduces coordination challenges. Research into optimistic constructions and hierarchical designs aims to reduce this friction.

Splicing

Splicing allows the capacity of an existing channel to be increased (splice-in) or decreased (splice-out) without closing and reopening it. Before splicing, if Alice wanted to add more funds to her channel with Bob, she would have to close the existing channel and open a new, larger one -- two on-chain transactions. With splicing, a single on-chain transaction modifies the funding output while the channel remains operational.

During a splice, the old and new funding outputs coexist briefly. Both parties maintain commitment transactions for both the old and new states until the splice transaction is confirmed on-chain. Once confirmed, the old funding output is spent and only the new channel state is active.

Splicing also enables seamless interoperability between on-chain and off-chain funds. A splice-out can send part of the channel's funds to an arbitrary on-chain address, effectively making the Lightning channel function as a wallet that can make both on-chain and off-chain payments without the user needing to think about the distinction.

Taproot Channels

Taproot (activated on Bitcoin in November 2021) introduces Schnorr signatures and a new script structure (MAST -- Merkelized Alternative Script Trees) that significantly improve Lightning channel efficiency and privacy.

Taproot channels use these features in several ways:

• Cooperative closes look like regular payments -- A cooperatively closed Taproot channel produces a transaction that is indistinguishable from an ordinary single-signature payment on the blockchain. The 2-of-2 multisig is hidden inside an aggregated Schnorr key. No observer can tell that the transaction was a channel close.
• Reduced on-chain footprint -- Taproot's key-path spending means the common case (cooperative close) requires only a single 64-byte signature, compared to two signatures and a redeem script for legacy P2WSH channels.
• PTLCs instead of HTLCs -- Taproot enables Point Time-Locked Contracts (PTLCs), which replace hash locks with elliptic curve point locks. PTLCs break the correlation between hops: each hop uses a different point, so a routing node that sees the same hash on two of its channels (revealing it is on the same path) can no longer make that inference.
• Improved script privacy -- The penalty and time-lock scripts are moved into Taproot script-path leaves, only revealed on-chain if the non-cooperative path is taken.

Taproot channels are being deployed incrementally. LND (Lightning Labs' implementation) shipped experimental Taproot channel support in 2024, and other implementations are following.

Lightning Service Providers (LSPs)

For everyday users, managing channel liquidity, running a node, and staying online for watchtower duties is impractical. Lightning Service Providers (LSPs) fill this gap by offering managed Lightning infrastructure.

An LSP typically provides:

• Inbound liquidity -- Opening channels to the user so they can receive payments immediately, without needing to first fund a channel themselves.
• Channel management -- Automatically rebalancing, opening, and closing channels to maintain payment reliability.
• Just-in-time (JIT) channels -- Opening a channel on the fly when an incoming payment is detected, funded by the payment itself. The user does not need to pre-arrange inbound capacity.
• Watchtower services -- Monitoring the blockchain on behalf of mobile users who are intermittently online.
• Liquidity leasing -- Renting channel capacity to other nodes, creating a market for inbound liquidity.

LSPs occupy a similar role to ISPs in the internet: most users do not run their own autonomous system or BGP router. They connect through a provider that handles the infrastructure complexity. The key architectural difference is that Lightning users retain self-custody of their funds even when using an LSP -- the LSP cannot seize the user's balance because the commitment transactions are pre-signed and can be broadcast unilaterally.

Network Topology: Hub-and-Spoke vs Mesh

The Lightning Network's topology has been a subject of ongoing analysis and debate. In theory, anyone can open a channel with anyone, creating a flat mesh. In practice, the network exhibits a pronounced hub-and-spoke pattern, similar to the peering hierarchy of the internet's BGP topology.

A small number of well-capitalized routing nodes -- entities like ACINQ, Lightning Labs, River, and Bitrefill -- maintain hundreds or thousands of channels and carry a disproportionate share of routed payments. These nodes function like Internet Exchange Points: highly connected hubs that reduce the average path length between any two nodes in the network.

Topological analysis of the Lightning Network reveals:

• Power-law degree distribution -- A few nodes have thousands of channels; most nodes have fewer than ten. This follows the same pattern seen in BGP's AS-level topology, where a handful of Tier 1 transit providers connect to hundreds of peers while most stub ASes have one or two upstreams.
• Small-world properties -- Despite having over 15,000 nodes, the average shortest path length is around 3-4 hops. This is because the hub nodes serve as shortcuts, connecting distant parts of the network.
• Centralization concerns -- If a major hub goes offline, payment reliability drops significantly for nodes that relied on it for connectivity. This mirrors the concern in BGP about the impact of a large transit provider failure, though the consequences are different (failed payments vs unreachable networks).

The network is slowly becoming more distributed as more LSPs and routing nodes enter the market, but the hub-and-spoke structure is likely a stable equilibrium: routing nodes with more connections attract more traffic, earn more fees, and can invest in more channels. This is the same feedback loop that creates Tier 1 networks in the internet routing ecosystem.

Comparison to Ethereum L2 Rollups

Both the Lightning Network and Ethereum's Layer 2 rollups (Optimistic Rollups like Arbitrum and Optimism, ZK-Rollups like zkSync and StarkNet) are designed to scale their respective base layers by moving computation and state updates off-chain. But their architectures differ fundamentally:

Lightning optimizes for a narrow use case -- payments -- and achieves unmatched speed and privacy for that use case. Rollups optimize for generality -- any smart contract logic can run on L2 -- at the cost of higher latency and weaker privacy. They solve different problems, and the tradeoffs reflect the different design philosophies of their respective base layers.

One area where they converge is the need for on-chain footprint reduction. Lightning's channel factories and Ethereum's blob transactions (EIP-4844/Danksharding) both aim to amortize L1 costs across many L2 operations. And both face the same fundamental question: how much decentralization can be preserved when users increasingly interact with L1 through intermediary infrastructure (LSPs for Lightning, sequencers for rollups).

The Lightning Network and the Internet

There are deep structural parallels between the Lightning Network and the internet's routing infrastructure. Both are decentralized networks where participants make independent decisions about connections (channels vs peering sessions). Both exhibit power-law topology with a few dominant hubs. Both use layered architectures where the lower layer (Bitcoin/IP) provides basic connectivity and the upper layer (Lightning/BGP) provides efficient routing.

The onion routing in Lightning is a direct descendant of the same cryptographic approach used by Tor for anonymizing internet traffic. And the pathfinding challenges -- finding a route with sufficient capacity through a network with incomplete information -- mirror the challenges of inter-domain routing where each AS makes local decisions with limited global visibility.

The Lightning Network has reached a total capacity exceeding 5,000 BTC across roughly 75,000 channels connecting over 15,000 nodes. Transaction volume continues to grow, driven by use cases ranging from micropayments and tipping to remittances and point-of-sale payments, particularly in regions like El Salvador and parts of Sub-Saharan Africa where the traditional banking infrastructure is limited.

Explore the Networks

Lightning payment routing relies on the same physical internet infrastructure that BGP routes. Every Lightning node is reachable via an IP address that is routed through the global BGP table. You can look up the networks that host major Lightning infrastructure:

• AS16509 -- Amazon Web Services, hosting many Lightning nodes
• AS14061 -- DigitalOcean, popular for self-hosted nodes
• AS24940 -- Hetzner, a major European hosting provider
• AS13335 -- Cloudflare, providing DDoS protection for Lightning web services