The contract
An HTLC is an output with two paths: pay to the recipient if they present the preimage s of a hash H before a timeout, or refund to the sender after it. On Lightning, HTLCs are added as extra outputs to the commitment transactions, so they live inside the channel until settled.
The payment, hop by hop
- Carol generates a random secret s and gives Alice H = hash(s) inside an invoice.
- Alice offers Bob an HTLC: 1,001 sats (payment plus Bob's fee) if he shows s before block T+40; otherwise refund.
- Bob offers Carol an HTLC: 1,000 sats if she shows s before block T+20.
- Carol reveals s to Bob to claim her 1,000 sats.
- Bob now knows s and reveals it to Alice to claim his 1,001.
Bob's deadline from Alice is later than the one he gave Carol, so he always has time to claim upstream after being claimed downstream. If Carol never reveals s, every HTLC times out and refunds; nobody loses. Bob never risks his own funds, and he never needed to trust Alice or Carol.
Why the timeouts shrink along the route
Each hop needs a margin to react. The sender's timeout is the largest; it decreases toward the receiver. This limits route length, and a payment "stuck" in flight ties up liquidity until it resolves, which is a known nuisance.
The privacy cost
Every hop on a route sees the same H, so colluding nodes can tell they are on the same payment. The fix is PTLCs (lesson 6).
On-chain fallback
If a channel force-closes with HTLCs in flight, they become real on-chain outputs that must be claimed or refunded by their timeouts. This is why Lightning needs predictable on-chain fees and why channel partners watch the chain.
A route has four hops and each hop needs a safety margin of 40 blocks. If the final hop's HTLC expires at block 900,040, when must the sender's HTLC expire at the earliest?