Blockchain/Level V · Layers/5.1 Lightning/Lesson 2
Routing with HTLCs
One secret, many hops, and the onion that hides the route
MaterialsA Lightning Network explorer (e.g., 1ML or mempool.space)The BOLT #2 and #4 specifications
Wonder
- How does a payment succeed for every participant or fail for all of them?
- Why must each node in a route know only its immediate predecessor and successor?
- What happens to a forwarded payment if the final recipient never claims it?
Explore
- Alice pays Carol through Bob without a direct channel. Each hop is an HTLC locked to the same payment hash, with timelocks decreasing along the route so each forwarder has time to claim upstream after paying downstream. When Carol reveals the preimage to claim, it flows back hop by hop, settling every HTLC.
- The sender chooses the route from the gossiped channel graph (source routing) and wraps instructions in layered encryption (Sphinx onion routing), so each node knows only its predecessor and successor. Forwarders charge a base fee plus a proportional fee (in parts per million). Payments fail when a hop lacks liquidity and are retried; multipath payments split large amounts.
- HTLCs are outputs within commitment transactions, not standalone entities. If a channel closes with pending HTLCs, the on-chain transaction includes additional outputs for each active contract. When an HTLC expires or succeeds while the channel remains open, new commitment transactions remove those outputs, reflecting the stable state.
- Lightning amounts are counted in millisatoshis, but an on-chain output must be worth more than the dust limit. HTLCs too small to be economical on-chain are ‘trimmed’: they get no output of their own in the commitment transaction, and their value is counted toward the transaction fee instead.
- A trimmed HTLC is therefore protected only by the counterparty’s good behavior: if the channel is force-closed while it is pending, the amount goes to miners. Nodes cap the total value of trimmed HTLCs they will accept, and many set a minimum HTLC size, accepting a small risk on tiny payments in exchange for supporting them at all.
- During a cooperative closure with an active HTLC, both parties halt new payment acceptance and wait for existing contracts to resolve or expire. This permits publishing a lighter closing transaction without HTLC-related outputs, reducing on-chain transaction fees and avoiding the mandatory timelock waits associated with contested closures.
Key facts
- HTLCs are outputs in commitment transactions that enable trustless routing across multiple channels.
- Sphinx onion routing ensures each node knows only its immediate predecessor and successor.
- Forwarders charge a base fee plus a proportional fee measured in parts per million.
- HTLCs below the dust limit are ‘trimmed’: counted toward fees instead of getting their own output.
- Cooperative closures with active HTLCs wait for resolution to avoid timelock waits and reduce fees.
- Multipath payments split large amounts across multiple routes to increase success rates.
Exercise nine, six, three, one
9CollectList 9 Lightning Network nodes or services. Note their routing policies, fee structures, and channel capacities.
6ClusterGroup the 9 into 6 by how they handle HTLCs: high-fee/high-capacity, low-fee/low-capacity, multipath-enabled, sub-dust-tolerant, cooperative-closure-priority, or other.
3DistillReduce the 6 to 3 reasons operators adjust their routing policies and fee structures.
1CrystallizeWrite 1 sentence on what an HTLC guarantees and what keeps that guarantee atomic.
Fact check
Dates, figures and claims checked against the published sources listed below.