How Lightning Network Routing Finds a Path for Payments

Lightning Network routing is the process of finding a chain of connected, sufficiently funded payment channels between a sender and a receiver so a payment can hop across the network without either party needing a direct channel with each other. It works without a central coordinator because senders compute their own routes using a map of the network's public channels.

This routing layer is what turns Lightning from a collection of isolated two-party channels into an actual payment network. If you haven't yet read about the channel mechanics themselves, our explainer on how Lightning payment channels actually work covers the HTLC foundation this article builds on.

The network graph

Every node that wants to be discoverable for routing announces its public channels — how much total capacity they hold and with whom — to the rest of the network through a gossip protocol. Your wallet (or the node it connects to) downloads this graph and uses it to calculate possible paths, similar in spirit to how a mapping app calculates a driving route from a map of roads and their capacities, except the "roads" here are payment channels and the "capacity" is how much value can currently flow in each direction.

Notably, only total channel capacity is public — the actual balance split between the two channel partners at any given moment is private. This means a sender's route calculation is always somewhat probabilistic: a channel might show 0.05 BTC total capacity, but if the partner has already spent most of what's theirs in that direction, an attempted payment through it will fail even though the channel "looks" viable on paper.

Multi-hop payments step by step

Say Alice wants to pay Carol, but they have no direct channel. Alice's wallet finds that Bob has channels with both of them. It constructs a route: Alice → Bob → Carol. Using the HTLC mechanism, Alice creates a conditional payment to Bob that only completes if Bob can prove he paid Carol (via the shared cryptographic secret), and Bob creates a matching conditional payment to Carol. When Carol claims her payment by revealing the secret, that secret cascades backward, letting Bob claim his hop of the payment from Alice, and the whole route settles atomically.

Bob, as the routing intermediary, typically earns a small fee for providing this pathway — usually a flat baseline fee plus a proportional fee based on the payment amount. This is the economic incentive that keeps well-connected nodes routing traffic for others.

Why payments fail to route

A "no route found" or "payment failed" error is common on Lightning and usually reflects one of these situations rather than a fundamental problem:

• Insufficient liquidity in the right direction: a channel along the path exists but doesn't currently have enough balance oriented toward the recipient.
• Fee mismatches: the sender's wallet may cap the routing fee it's willing to pay, and if no viable path meets that cap, the payment fails.
• Time-lock limits: HTLCs use a time-lock (CLTV) that shortens at each hop; very long routes can run into limits that some node implementations enforce.
• Offline nodes: if an intermediary node in the calculated route is temporarily offline, the payment attempt through that path fails and the wallet must retry with an alternative route.

Wallets typically retry automatically with different paths when the first attempt fails, which is why most payments still succeed even though liquidity is unevenly distributed across the network.

Techniques that improve routing success

Multi-path payments (MPP) split a single payment across several routes simultaneously, so instead of needing one path with the full amount of liquidity, smaller portions can be routed through multiple partial paths and reassembled by the recipient. This significantly improves success rates for larger payments. Well-connected, well-capitalized routing nodes ("hubs") also improve overall network reliability by providing many possible paths between otherwise distant parts of the graph.

Routing versus on-chain settlement

Aspect	Lightning routing	On-chain transaction
Path required	Yes, chain of funded channels	No, direct to any address
Failure mode	Can fail due to liquidity gaps	Rarely fails, just costs more in fees
Speed	Seconds	Minutes
Visibility	Only total channel capacity public	Full transaction history public

For a deeper comparison of the tradeoffs at stake, see Lightning Network vs on-chain Bitcoin.

Bottom line

Lightning routing works by treating the network of public channels like a map, computing a path with enough available liquidity, and using chained HTLCs to make the multi-hop payment atomic. Routing failures are a normal, expected part of using a liquidity-constrained network rather than a sign something is broken, and techniques like multi-path payments continue to improve success rates as the network matures.