HTLC (Hashed Timelock Contract)

A Hashed Timelock Contract (HTLC) is the conditional payment primitive at the heart of every Lightning Network transaction. It locks funds against two conditions enforced by Bitcoin Script: a hashlock, which releases the money only when a secret value (the preimage) matching a known hash is revealed, and a timelock, which refunds the sender if that secret never appears before a deadline.

How HTLCs enable multi-hop payments

The recipient generates a random 32-byte preimage and shares only its SHA-256 hash inside the invoice. The sender constructs a chain of HTLCs across each channel on the route, all locked to that same hash. When the recipient claims the final HTLC by revealing the preimage, each intermediate routing node learns the secret and pulls payment from the hop before it. Either the whole payment settles or none of it does, giving Lightning its atomic, trustless character.

The timelock safety net

Each hop's timelock (expressed as a CLTV delta) decreases toward the destination, guaranteeing an upstream node always has time to react before its downstream HTLC can be reversed. If a route stalls, the timelock lets the sender reclaim funds on-chain without trusting any intermediary.

HTLCs depend on the payment channel structure and are forwarded using onion routing across routing nodes. The same hashlock idea underpins atomic swaps and submarine swaps.

What HTLCs Cost, and Why Channels Limit Them

Every HTLC in flight is not just protocol state — it is a real output added to both parties' commitment transactions, with its own script and its own claim on the channel's funds. That has hard consequences: each pending HTLC makes the commitment transaction larger (and costlier to enforce on-chain if the channel force-closes), so the protocol caps how many can be outstanding per channel at once, and nodes enforce a minimum HTLC size because an output too small to economically claim on-chain is unenforceable in exactly the situation where enforcement matters. Amounts below that floor are handled as unenforceable “dust” balances — fine for tiny payments, but a reminder that Lightning's guarantees are anchored in what can actually be settled on the base layer.

When Things Stall: Timeouts and Force Closes

The happy path never touches the chain, but the timelock exists for the unhappy one. If a downstream node stops responding while holding an HTLC, its upstream peer faces a deadline: it must resolve the HTLC before the timelock expires or risk losing the amount if the secret surfaces late. The standard resolution is a force close — broadcasting the commitment transaction and settling the pending HTLC on-chain via its timeout or success path. This is why long-stalled payments can trigger cascading channel closures along a route, and why routing nodes care about peers' reliability: every hop that fails to settle cooperatively converts an off-chain update into on-chain fees.

Beyond Hashes: The Move Toward PTLCs

HTLCs share one identifying weakness: every hop on a route locks to the same hash, so colluding nodes at different points can recognize they are forwarding the same payment — a privacy leak baked into the construction. The proposed successor, the point time-locked contract (PTLC), replaces the hash secret with elliptic-curve points that can be re-blinded at each hop, made practical by Taproot's Schnorr signatures. Each hop then sees an unlinkable condition while atomicity is preserved. The economics and timeout logic carry over unchanged from the HTLC design described above — the channel capacity and settlement mechanics stay the same; what improves is how little the network learns about who paid whom. Understanding HTLCs first makes the upgrade legible: PTLCs change the lock, not the ladder of conditional commitments that makes routed payments trustless.