Overview
A Hash Time-Locked Contract (HTLC) is a conditional payment that combines two powerful primitives: a hash lock (requiring knowledge of a secret to claim funds) and a time lock (allowing the sender to reclaim funds after a deadline). HTLCs are the critical mechanism enabling multi-hop payments across the Lightning Network and trustless cross-chain atomic swaps, as they ensure that either all parties in a payment chain receive their funds or none do.
How an HTLC Works
Alice wants to pay Carol through Bob (Alice → Bob → Carol)
Step 1: Carol generates a random secret R and sends hash(R) to Alice
Step 2: Alice creates HTLC with Bob:
┌──────────────────────────────────────────────┐
│ HTLC: Alice → Bob │
│ │
│ IF Bob provides preimage R where │
│ hash(R) = H AND Bob's signature │
│ THEN Bob can claim funds │
│ │
│ IF timeout expires (e.g., 48 hours) │
│ THEN Alice can reclaim funds │
└──────────────────────────────────────────────┘
Step 3: Bob creates HTLC with Carol (same hash, shorter timeout):
┌──────────────────────────────────────────────┐
│ HTLC: Bob → Carol │
│ │
│ IF Carol provides preimage R where │
│ hash(R) = H AND Carol's signature │
│ THEN Carol can claim funds │
│ │
│ IF timeout expires (e.g., 24 hours) │
│ THEN Bob can reclaim funds │
└──────────────────────────────────────────────┘
Step 4: Carol reveals R to claim from Bob
Step 5: Bob now knows R, uses it to claim from Alice
The Two Lock Conditions
Hash Lock: The recipient must reveal a preimage (secret value) whose hash matches a predetermined hash value. This ensures that the secret propagates backward through the payment chain as each hop claims their payment.
Time Lock: If the payment is not claimed within a specified time window, the sender can reclaim the funds. Time locks decrease at each hop (e.g., 48h, 24h, 12h) to ensure each intermediary has time to claim after learning the secret.
Timelock structure across hops:
Alice ──[48h]──► Bob ──[24h]──► Carol
Carol claims first (knows the secret)
Bob claims second (learned secret from Carol)
Alice's timeout is longest (most time to resolve)
Security Properties
- Atomicity: Either the entire payment completes or none of it does. Carol cannot claim without revealing R, and Bob cannot claim without R.
- Trustless: No intermediary can steal funds. Bob cannot claim from Alice without first paying Carol (because he needs R).
- No counterparty risk on the secret: The hash function ensures the preimage cannot be guessed.
HTLCs in Practice
In the Lightning Network, HTLCs are typically resolved off-chain through the normal channel update mechanism. The on-chain HTLC script is only used as a fallback if a party becomes unresponsive or attempts to cheat. This means that in practice, multi-hop Lightning payments complete in seconds without touching the blockchain.
Limitations
- Locked liquidity: Funds in an HTLC are locked until the payment completes or times out, temporarily reducing available channel capacity
- Routing correlation: The same hash is used across all hops, making it theoretically possible for a node controlling multiple hops to correlate them (PTLCs, using point locks instead of hash locks, address this)
- Timeout risks: If a node goes offline during the timeout window, funds may be locked until the timelock expires
Common Misconceptions
- HTLCs are not unique to the Lightning Network. They can be used on-chain and are the foundation of atomic swaps between different blockchains.
- The "hash" in HTLC refers to the hash of the secret preimage, not to Bitcoin's proof-of-work hashing.
- HTLCs do not require trust in any intermediary. The cryptographic construction ensures that forwarding nodes cannot steal funds.