HTLC (Hash Time-Locked Contract)

What Is an HTLC?

A Hash Time-Locked Contract (HTLC) is a conditional payment that uses two cryptographic primitives to guarantee trustless execution: a hash lock and a time lock. The recipient must produce a secret value (the preimage of a hash) to claim the payment, and the sender can reclaim the funds if the recipient fails to do so before a deadline. No third party arbitrates the outcome: the conditions are enforced by script on-chain or by channel update mechanisms off-chain.

Think of it like a locked safe with two keys. The first key is the secret code: if you know it, you can open the safe and take the money at any time. The second key is a timer: if nobody opens the safe before the clock runs out, the money returns to the sender automatically. These two conditions working together eliminate the need for trust between parties.

HTLCs originated in early atomic swap proposals and became the foundational building block of the Lightning Network. Every standard Lightning payment uses a chain of HTLCs to route value from sender to receiver across one or more intermediary nodes.

How It Works

An HTLC has two spending conditions encoded in Bitcoin Script (on-chain) or in channel commitment transactions (off-chain):

1. Hashlock path: the recipient can claim the funds by presenting a value R (the preimage) such that SHA256(R) equals the agreed payment hash H.
2. Timelock path: if the preimage is not revealed before a specified block height or time, the sender can reclaim the funds using the timeout refund path.

On-Chain HTLC Script

An on-chain HTLC is a Bitcoin output with a script that encodes both conditions. A simplified version looks like this:

OP_IF
  OP_SHA256 <payment_hash> OP_EQUALVERIFY
  <recipient_pubkey> OP_CHECKSIG
OP_ELSE
  <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <sender_pubkey> OP_CHECKSIG
OP_ENDIF

The OP_IF branch is the hashlock path: the recipient provides the preimage and their signature. The OP_ELSE branch is the timelock path: after the timeout, the sender provides their signature to reclaim funds.

Off-Chain HTLCs in Lightning

In the Lightning Network, HTLCs are not broadcast to the blockchain unless a channel is force-closed. Instead, they exist as pending outputs in commitment transactions that both channel partners hold. When an HTLC is added to a channel:

1. The offering node proposes an HTLC via the update_add_htlc message, specifying the payment hash, amount, and expiry
2. Both parties update their commitment transactions to include the new HTLC output
3. They exchange signatures using commitment_signed and revoke_and_ack messages
4. When the preimage is revealed, both parties update their commitments to remove the HTLC and shift the balance to the recipient

If a dispute arises, either party can broadcast their commitment transaction. The HTLC output on-chain then follows the same hashlock and timelock rules. A watchtower can monitor for outdated commitment broadcasts and trigger a justice transaction if a party tries to cheat.

Multi-Hop Routing

The real power of HTLCs emerges in multi-hop payments. When Alice wants to pay Carol but has no direct channel, the payment can route through an intermediary node (Bob). The same payment hash links all hops into one atomic operation:

Alice ──HTLC(H, 1000 sat, T+30)──▶ Bob ──HTLC(H, 1000 sat, T+20)──▶ Carol

Step 1: Carol generates preimage R, computes H = SHA256(R)
Step 2: Carol shares H with Alice (via invoice)
Step 3: Alice creates HTLC to Bob: "1000 sat if you show me R before block T+30"
Step 4: Bob creates HTLC to Carol: "1000 sat if you show me R before block T+20"
Step 5: Carol reveals R to Bob, claims 1000 sat
Step 6: Bob reveals R to Alice, claims 1000 sat
Step 7: Payment complete: Alice paid Carol through Bob

Notice the decreasing timelocks: Bob's HTLC to Carol expires at T+20, while Alice's HTLC to Bob expires at T+30. This gives Bob a 10-block window to claim from Alice after learning the preimage from Carol. Without this staggering, a routing node could lose funds if both HTLCs expired simultaneously.

This pattern extends to any number of hops. Each intermediary forwards the HTLC with a shorter timelock and a small fee deducted from the amount. The atomic guarantee holds across the entire path: either all hops settle (when the preimage propagates back) or none do (when timeouts expire).

HTLC and Anchor Outputs

When a channel force-closes with pending HTLCs, those HTLC outputs must be resolved on-chain within their timelock windows. Anchor outputs allow either party to fee-bump the commitment transaction and HTLC transactions via CPFP (Child Pays for Parent), ensuring that time-sensitive HTLC claims confirm before their deadlines even during fee spikes.

Use Cases

Lightning Network Payments

Every standard Lightning payment uses HTLCs. When you pay a Lightning invoice, your node constructs a route and creates a chain of HTLCs from your node to the recipient. The recipient reveals the preimage, and settlement cascades back through every hop. This is the mechanism described in zero-conf Bitcoin research that enables instant, low-fee Bitcoin transactions.

Hodl Invoices

Hodl invoices exploit the HTLC mechanism by deliberately delaying preimage revelation. The receiver holds the HTLC open and decides whether to settle or cancel based on external conditions. This enables escrow-like functionality, marketplace payments, and conditional settlement: all built on the HTLC primitive.

Atomic Swaps

HTLCs enable trustless exchanges across different blockchains. Two parties create HTLCs on separate chains using the same payment hash. Claiming on one chain reveals the preimage, which unlocks the HTLC on the other chain. This guarantees atomicity: either both swaps complete or neither does.

Submarine Swaps and Loop

Loop In/Out operations use HTLCs to bridge on-chain and off-chain Bitcoin. A submarine swap pairs an on-chain HTLC with an off-chain Lightning HTLC using the same hash. This allows channel rebalancing and on/off-ramps without closing channels.

Atomic Multipath Payments

Atomic multipath payments (AMPs) split a single payment across multiple routes. Each partial payment uses its own HTLC, but they all share the same payment hash. The receiver only claims the preimage once all parts arrive, ensuring the payment is all-or-nothing even when split across the network.

Risks and Considerations

Privacy: Payment Hash Correlation

The most significant limitation of HTLCs is that every hop in a payment route uses the same payment hash. Any node that appears in two different payment paths can correlate them. A routing node that handles two hops of the same payment learns that those hops are part of one transaction. This is a form of probing vulnerability that degrades sender and receiver privacy.

This is why the community is working toward PTLCs: they use different adaptor signatures at each hop, making correlation across hops impossible.

Timelock Griefing

A malicious actor can lock up liquidity across the network by creating HTLCs and never settling them. The sender's funds (and every routing node's liquidity along the path) remain locked until the timelock expires. In multi-hop routes with long timelocks, this can immobilize significant capital.

Proposed mitigations include HTLC endorsement signals, reputation-based forwarding, and upfront fees for HTLC slot usage. Shorter CLTV deltas also reduce the griefing window but increase the risk of legitimate payments failing due to slow on-chain confirmations.

Dust HTLCs

HTLCs below the dust threshold cannot be economically claimed on-chain. If a channel force-closes with dust-value HTLCs, those funds go to miners as fees rather than being resolved. Ephemeral dust handling and anchor outputs help mitigate this, but very small HTLCs remain a special case that implementations must handle carefully.

HTLC Slot Limits

Lightning channels have a maximum number of concurrent HTLCs (typically 483 per direction, limited by the Bitcoin transaction size). If a channel fills its HTLC slots, it cannot route additional payments until existing HTLCs resolve. This creates a denial-of-service vector: an attacker can flood a channel with small HTLCs to block legitimate traffic.

The Transition to PTLCs

PTLCs (Point Time-Locked Contracts) are the planned successor to HTLCs. They replace hash locks with adaptor signatures based on elliptic curve points, providing two major improvements:

• Each hop uses a different point, preventing payment correlation across the route
• They are more compact on-chain, reducing fees for force-close HTLC resolution

PTLCs require Schnorr signatures, which are available on Bitcoin since the Taproot upgrade. Adoption depends on Lightning implementations updating their channel protocols. Proposals like eltoo further complement PTLCs by simplifying channel state management.

Frequently Asked Questions

How is an HTLC different from a regular Bitcoin transaction?

A regular Bitcoin transaction transfers funds unconditionally: once broadcast and confirmed, the recipient owns the output. An HTLC adds two conditions: the recipient must reveal a preimage (hashlock) or the sender can reclaim funds after a timeout (timelock). This conditionality enables atomic multi-party protocols that simple transfers cannot achieve.

What happens if a routing node goes offline during an HTLC?

If a routing node goes offline, the HTLC cannot settle through them. The timelock ensures that funds are not lost: once the expiry passes, the sender (or preceding hop) reclaims the funds via the timeout path. A watchtower can monitor the chain and submit timeout transactions on behalf of an offline node.

Can HTLCs be used with keysend payments?

Keysend payments are a special case where the sender generates the preimage instead of the receiver. The payment still uses HTLCs for routing, but the sender includes the preimage in the encrypted onion payload. The receiver extracts it and settles immediately. This enables spontaneous payments without requiring an invoice.

How do HTLCs relate to channel capacity?

Each pending HTLC consumes channel capacity on both sides of the route. The HTLC amount is deducted from the sender's balance but not yet added to the receiver's balance: it sits in limbo as a separate output. The channel reserve requirement ensures that both parties always maintain a minimum balance, preventing scenarios where a party has nothing to lose from cheating.

This article is for informational purposes only and does not constitute financial, legal, or technical advice. Always conduct your own research before making decisions related to cryptocurrency or blockchain technology.