HTLC

Hash time-locked contracts are what make a multi-hop Lightning payment safe to forward. Each hop locks its money to the same SHA-256 hash, and a channel may carry at most 483 of them in each direction at once. For you, that is why a Lightning payment either settles completely or fails completely, and never strands money halfway along the route.

How it works

Two conditions guard the money in an HTLC, and exactly one of them will eventually be true.

The receiver invents a random 32 byte secret, called the preimage, hashes it with SHA-256, and puts the result in the invoice. Every node along the route then offers the next node an output spendable in two ways: immediately by anyone who can show the preimage, or, after an agreed block height, by the node that offered it. Because all hops share one hash, the moment the receiver claims their money by revealing the preimage, every earlier hop learns it and claims theirs. Nobody is ever left having paid forward without being paid back, which is the property Lightning is built on.

The block heights step down along the route. Each channel advertises a cltv_expiry_delta, and the payer stacks those deltas so the hop nearest the receiver expires first and every hop upstream has a safety margin. BOLT 11 tells a payer to allow at least 18 blocks for the final hop when the invoice does not say otherwise. That accumulated delay is the real cost of an HTLC: if a payment jams, the money is not lost, but it can be frozen for hours while the timeouts unwind.

On chain these contracts become real transactions. In an anchor channel, an HTLC-timeout transaction weighs 666 weight units and an HTLC-success transaction weighs 706, and a force close with several payments in flight means broadcasting one of these for each of them. Amounts too small to be worth an output are not given one at all; they are added to the mining fee instead, which is why a tiny payment can vanish into fees if a channel closes at the wrong moment.

Where you see it

You see HTLCs in the seconds between tapping pay and the invoice going green, and you see them again in the fee math of an on-chain swap.

Lightning-first services such as Strike move money this way on every payment, and Lightning routing nodes list the count of pending HTLCs as an operational metric, because a channel stuffed with stuck contracts cannot forward anything. The same construction works outside Lightning: a submarine swap trades an on-chain HTLC against a Lightning payment locked to the identical hash, and a cross-chain atomic swap does the same across two ledgers. In each case the hash is the shared referee and the timeout is the refund.

The cap matters more than it looks. A commitment transaction has to stay a valid bitcoin transaction, so BOLT 2 forbids more than 483 accepted contracts per direction, dropping to 114 for the newer zero-fee commitment format. Big routing channels bump into that ceiling during busy periods, which is one honest reason a payment sometimes fails and succeeds thirty seconds later.

HTLC vs PTLC

An HTLC uses one hash for the whole route, while a PTLC gives every hop a different lock derived from an elliptic curve point. That single difference is a privacy hole: two routing nodes owned by the same operator, sitting at different points on your route, can see the same hash twice and stitch your payment together. HTLCs are what the network actually runs on. PTLCs are the specified replacement, and until they ship, assume any large routing operator can correlate the hops it forwards.