HTLCs (Hash Time Locked Contracts) are conditional payments: claim with a preimage before timeout, otherwise refund. Chained HTLCs create atomic multi-hop Lightning payments.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: same hash, decreasing timelocks
Every routed payment is an HTLC dance. Debugging failures means reading hashes, CLTV deltas, and onion errors — not guessing.
Analogy: A locked briefcase opens with a secret word (preimage). Each courier holds a briefcase with the same word requirement but earlier deadlines. When the final person learns the word, it propagates back so everyone can settle.
Loading diagram…
Each hop needs enough timelock margin. Implementations enforce minimums — do not invent tighter custom deltas without reading BOLTs. Modern invoices include a payment secret so intermediaries cannot settle incorrectly. While an HTLC is outstanding, that slice of outbound is reserved — ties back to channel liquidity.
Done when: You can contrast payment hash vs preimage and why CLTV shrinks toward the payee.
Step 3 — Try it: path pay (lab)
Pay across a 2–3 node Polar path. Optionally fail mid-route and compare unwind vs successful settle.
Common mistakes
- Confusing payment hash with payment secret
- Setting timelock deltas too tight for hops
- Ignoring that held HTLCs lock liquidity
Done when: Lab evidence (pay proof + hash/preimage sentence + CLTV note + source) is complete.
Next lesson
Channel Lifecycle — cooperative close, force close, and backups.