Model 17 · Network
The Lightning Routing Machine
Paying across a network of channels.
Explanation level
How to use this model
How to use this modelWhat you see, what you can touch, what changes, what to take away
What am I looking at?
A plate of participant pucks joined by channel rails; each rail is split by a bead into its two sides' liquidity, and an orange payment bead hops along the chosen route.
What can I touch?
- Select a sender
- Select a receiver
- Choose a payment amount
- Explore possible routes
What happens when I change something?
Move a channel's bead, raise a fee or disconnect a rail, and the cheapest route changes; if a hop lacks liquidity on its sending side the payment stops there and the next route is tried.
What should I understand afterwards?
Explain how a payment can reach someone without a direct channel.
Understand why Lightning payments can travel through connected participants.
A payment passed hand to hand.
After this you can
- Explain how a payment can reach someone without a direct channel.
Experiment with routes, fees and liquidity.
Change splits, fees and connections; send and retry.
After this you can
- Predict when a route fails because a hop lacks liquidity on the sending side.
Explore HTLCs, payment hashes, routing fees and multi-hop settlement.
Hop amounts, base + ppm fees, preimage settlement.
After this you can
- Compute hop amounts and routing fees backwards from the receiver.
Open the model in its own window · works offline once loaded
Missions operate the model to complete them
-
When the cheapest route fails
IntermediateCompletedSee a payment succeed only after the cheapest route ran out of liquidity.
Your task: Send 100,000 sat from Alice to Bob in the starting network and watch what happens to the first route.
Use: Select a sender · Select a receiver · Choose a payment amount · Observe failed payments · Retry through alternative routes
The sender sees capacities and fees, not how each channel's capacity is split. The cheapest route can fail at a hop without enough liquidity on its sending side; the sender learns from the failure and tries another route.
Missions are checked from the model's own simulation state, not from clicks. No time limit. Completion is stored only in this browser. The quiz questions in the learning paths remain available.
Tutor Ask a question, or let the tutor show you around
The tutor answers by explaining and, within the permissions below, by operating this model. Every change it makes is shown and listed, and you can undo it. It cannot run code, read your browser data or see anything secret. The page works the same without it.
What the tutor did
Common mix-ups
- Myth: If two people are connected through channels, a payment between them always works.
- In fact: Each hop needs enough liquidity on its sending side; capacity alone does not decide it.
- Myth: Senders see every channel's balance.
- In fact: For announced channels only capacities and fee policies are public (unannounced channels are not in the public graph at all); senders discover failures by trying.
Concepts in this model
Helpful to know first
Next recommended
Part of these learning paths