Lightning Routing
Finding a path of LN channels from sender to recipient, potentially spanning multiple intermediaries.
Lightning routing is the process of finding a path through the network of Lightning channels that can carry your payment from sender to receiver, when no direct channel exists between them.
Most Lightning users don't have direct channels with the people they pay - that would require opening an on-chain transaction with every counterparty, defeating the point. Instead, your Lightning node routes payments through intermediate nodes that do have a path to the destination, atomically, via chained HTLCs.
How it works under the hood:
- Build the graph. Lightning nodes share a gossip protocol advertising which channels exist, their capacity, and their fee policies. Your node maintains a local view of this graph.
- Find a path. Run a modified Dijkstra's algorithm to find a sequence of channels from you to the destination, with enough capacity on the relevant side of each channel, optimizing for fees and reliability.
- Onion-route the payment. Each hop knows only the previous and next hop, not the full path. This is Sphinx onion routing, similar to Tor.
- HTLCs lock the payment at every hop. If any hop fails, the whole payment unwinds atomically - you don't lose money in a partial route.
- If routing fails, retry. Modern wallets retry with different paths or split the payment across multiple paths (Atomic Multi-Path Payments / AMP).
The hard problems in routing:
- Liquidity is private. Gossip tells you channels exist and their total capacity, but not which side has the balance. Routing has to probe or guess.
- Channels deplete. A channel that worked for routing a minute ago might be depleted on the relevant side after your payment passed through. Other people's payments are invisible to you.
- Larger payments are harder. Probability of finding a complete path drops as payment size approaches typical channel capacity. AMP and channel splicing help, but huge payments often require multiple attempts or out-of-band coordination.
Routing reliability has improved dramatically since 2020 - most everyday payments under a few hundred thousand sats route on the first try. Larger or more remote payments still occasionally fail, but the failure modes are recoverable and never lose funds.
See the Lightning Routing rabbit hole for the deeper treatment - source routing, onion encryption, multi-path payments, pathfinding heuristics, and the probing techniques wallets use to find liquidity.
Key takeaways
- Selects a route of connected channels with sufficient capacity
- Uses LN gossip data for up-to-date channel states
- Relies on ephemeral HTLCs ensuring trustless multi-hop payments
Related terms (25)
- Atomic Multi-Path Payment (AMP)
- BOLT
- BOLT 11
- Bridge Node (Lightning)
- Churn (Lightning)
- Core Lightning (c-lightning)
- Delayed Payment Channel
- Gossip Protocol (Lightning)
- HTLC (Hashed Time-Locked Contract)
- HTLC Invoice
- HTLC Preimage Manager
- Jamming Attack (LN)
- Jammed HTLC Detector
- Lightning Channel
- Lightning Channel Capacity
- Lightning Channel Splicing
- Lightning Invoice
- Lightning Network
- Lightning Network Daemon (lnd)
- Lightning Node
- Lightning Payment
- Lightning Probe
- Lightning Refund Invoice
- Lightning Sphinx
- Onion Routing (Lightning)