Routing is liquidity-aware path selection. The payer (usually) constructs a path across the public graph plus hints, then onion-encrypts hop instructions. Every hop must have enough outbound on the forward edge.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: cheap ≠ successful
Routing success rates define UX. A path that looks cheap on fees still fails if any hop lacks outbound. Fee-aware, reliability-aware pathfinding separates toy demos from production wallets.
Analogy: You plan a road trip with toll costs and bridge weight limits. If a bridge is “full” (insufficient balance), you detour — often without knowing exact traffic until you try.
Loading diagram…
Factor in: fees, CLTV budget, max HTLC / capacity, private channel hints from invoices, and learned reliability (mission-control style).
Done when: You can name three inputs to route choice beyond “lowest fee.”
Step 3 — Try a path (lab)
Multi-hop pay on Polar. Note which constraint bit you if it fails. Optional Amboss skim for graph intuition.
Common mistakes
- Optimizing only for lowest fee and ignoring success probability
- Ignoring max HTLC / capacity constraints
- Forgetting private channel hints from invoices
Done when: Lab evidence (attempt + factor list + source) is complete.
Next lesson
Onion Routing — how hop payloads stay private.