Hashed Timelock Contract (HTLC)

A hashed timelock contract (HTLC) is a conditional payment on a blockchain that combines two locks. A hashlock means the funds can be claimed only by someone who reveals a secret value, called a preimage, whose hash matches one written into the contract. A timelock means that if nobody claims the funds before a set time or block height, the sender can take them back. Together, the two conditions let people who do not trust each other exchange value safely.

HTLCs are a building block of the Lightning Network, where they let payments hop across several channels without any intermediary being able to steal them, and of atomic swaps, which exchange coins on two different blockchains without an exchange. They can be built with Bitcoin's scripting language and with smart contracts on networks such as Ethereum.

Imagine leaving a parcel in a locker with two rules. Whoever types in the right secret code can open it. But if nobody opens it by Friday, the locker automatically unlocks for the person who left the parcel. The recipient gets the parcel only by revealing the code, and the sender never loses it for good.

Now imagine two people each put something in a locker for the other, both locked with the same secret code. When one of them opens a locker with the code, the code becomes visible to the other, who can then open theirs. Either both swaps happen, or both parcels go back to their owners.

1. The recipient, or another party, chooses a random secret and calculates its hash using a function such as SHA-256. Only the hash is shared.
2. The sender locks funds in a contract that says: pay the recipient if they present data that hashes to this value before the deadline; otherwise refund the sender.
3. To claim the funds, the recipient publishes the secret in a transaction. Because the secret is now on the blockchain, anyone watching can see it.
4. If the deadline passes without a claim, the sender submits a refund transaction.

Bitcoin supports this through script operations that check a hash and enforce time conditions, including locktime features added to the protocol through soft forks in 2015 and 2016.

In the Lightning Network, a payment from Alice to Carol can pass through Bob, with whom both have payment channels. Carol creates a secret and gives Alice its hash. Alice offers Bob an HTLC: Bob can have the money if he shows the secret. Bob offers Carol a matching HTLC with a slightly earlier deadline. Carol reveals the secret to claim Bob's payment, and Bob uses the same secret to claim Alice's. Bob cannot take the money without passing it on, and the staggered deadlines protect him if Carol is slow. The same chain can stretch across many hops, which is how Lightning payments are routed, a process described under Lightning Network routing.

Two parties wanting to swap bitcoin for another coin each lock funds in an HTLC on their own chain, using the same hash. When one claims with the secret, the other learns it and claims on the second chain. If either fails to act, timelocks return the funds. This avoids trusting a centralized exchange, although it requires both chains to support compatible hash functions and time conditions. Similar ideas appear in some cross-chain protocols.

• Liveness required. Participants must be online to claim or refund before deadlines, or they may lose out.
• Capital locked up. Funds are tied up until the swap or payment completes or times out.
• Free option problem. In an atomic swap, the party holding the secret can wait and see whether prices move in their favour before completing, which gives them an unfair option.
• Privacy. Because the same hash appears at every step, observers can link the parts of a payment or swap; newer designs aim to reduce this.
• Fee spikes. High on-chain fees near a deadline can make it costly or slow to settle disputes, which matters for Lightning's security.

Despite these drawbacks, HTLCs remain one of the simplest tools for trust-minimized exchange and are a standard part of blockchain interoperability research.