Overview
Routing is the process by which a payment traverses multiple payment channels on the Lightning Network to reach a recipient that the sender does not have a direct channel with. The sender's node calculates a path through the network graph, constructs an onion-encrypted payment packet, and forwards it hop by hop until it reaches the destination. Routing nodes along the path can charge small fees for forwarding the payment.
How Routing Works
Alice wants to pay Dave but has no direct channel:
Alice ──── Bob ──── Carol ──── Dave
│ │ │ │
│ 0.5 │ 0.8 │ 0.6 │
│ local │ local │ local │
Payment route: Alice → Bob → Carol → Dave
Step 1: Alice finds path through network graph
Step 2: Alice constructs onion-encrypted packet
Step 3: Payment flows hop by hop:
Alice ──0.01 BTC──> Bob ──0.01 BTC──> Carol ──0.01 BTC──> Dave
- fee: 1 sat - fee: 1 sat (final hop)
Each hop only knows the previous and next hop
(onion routing provides privacy)
Source-Based Routing
Lightning uses source-based routing, meaning the sender calculates the complete path before sending the payment. This is in contrast to destination-based routing (used in IP networks) where each hop independently decides the next step. Source routing gives the sender control over the path and enables onion routing for privacy, but requires the sender to have a reasonably current view of the network's channel graph.
Routing Fees
Each routing node specifies two fee parameters in their channel policies:
- Base fee — A flat fee charged per forwarded payment (typically 0-1000 millisatoshis)
- Fee rate — A proportional fee based on the payment amount (typically 1-100 parts per million)
The sender's pathfinding algorithm considers fees when selecting a route, generally preferring lower-cost paths while also considering reliability and channel capacity.
Challenges
- Liquidity uncertainty — Channel balances are private, so the sender does not know if a channel has sufficient capacity until the payment attempt succeeds or fails
- Payment failures — If any hop along the path lacks sufficient liquidity, the payment fails and the sender must retry with a different route
- Large payments — Payments close to channel capacity limits are harder to route; Multi-Path Payments (MPP) split large payments across multiple routes
Multi-Path Payments (MPP)
To improve reliability for larger payments, the Lightning protocol supports splitting a payment into multiple smaller parts that take different routes through the network. Each part is atomic — either all parts succeed or the entire payment fails — thanks to the use of a single payment hash with multiple HTLCs.
Common Misconception
Routing nodes cannot steal funds in transit. The HTLC mechanism ensures that a routing node can only claim forwarded funds if it can prove the payment reached the next hop. If the payment fails at any point, all funds are returned to the sender along the reverse path.