Hash Time-Locked Contract (HTLC)

The hashlock is the cryptographic puzzle that secures the payment. The sender creates a cryptographic hash of a secret preimage. To claim the funds, the recipient must reveal this preimage, which produces a matching hash, proving they have the secret. This mechanism enables atomic swaps and cross-chain bridges without a trusted intermediary.

• Example: Alice sends BTC to a contract with hashlock H = SHA256(secret). Bob can only claim it by providing the secret that hashes to H.

The timelock is the fail-safe mechanism that prevents funds from being locked indefinitely. It defines a deadline (e.g., 48 hours) by which the cryptographic condition must be met. If the recipient fails to provide the secret preimage before the timelock expires, the sender can refund the locked funds. This creates a strict, self-enforcing timeline for the transaction.

• Types: Can be absolute (block height) or relative (blocks after an event).

HTLCs enable atomic cross-chain swaps, allowing two parties to exchange different cryptocurrencies without a centralized exchange. The process is atomic: either both parties complete the swap, or neither does. The hashlock ensures the secret is revealed upon the first claim, allowing the counterparty to immediately claim their side of the trade.

• Process: 1) Alice locks BTC with hashlock H. 2) Bob locks ETH with the same hashlock H. 3) Alice reveals secret to claim ETH, exposing it to Bob. 4) Bob uses secret to claim BTC.

HTLCs are the fundamental building block for payment channels and Layer 2 networks like the Lightning Network. They enable secure, off-chain routing of payments through a network of intermediaries. Each hop in the payment path is secured by its own HTLC with a sequentially shorter timelock, ensuring the payment either completes fully or can be rolled back at each step.

• Function: Allows multi-hop payments where no single node needs to be fully trusted.

The refund pathway is a guaranteed, built-in security feature. If the intended recipient is unresponsive or the transaction fails, the original sender can always reclaim their funds after the timelock expires. This eliminates the risk of permanent loss due to a counterparty's failure to act. The contract's logic autonomously enforces this, requiring no third-party intervention.

While powerful, HTLCs have specific constraints that developers must account for:

• Liquidity Lockup: Funds are immobilized for the duration of the timelock.
• Timelock Precision: Requires careful coordination of block times across different chains for cross-chain use.
• Hashlock Security: Relies on the cryptographic strength of the hash function (e.g., SHA-256) and the secrecy of the preimage.
• No Partial Execution: The contract state is binary—either fully completed or fully refunded.

While powerful, HTLCs have specific constraints:

• Timing Attacks: The refund time lock must be carefully calibrated across a payment route to prevent theft.
• Liquidity Lockup: Funds are immobilized for the duration of the time lock.
• On-Chain Cost: Disputes or settlements requiring on-chain execution incur transaction fees.
• Privacy: The hash is public, potentially allowing network observers to link transactions. Newer constructions like Point Time-Locked Contracts (PTLCs) using Schnorr signatures aim to improve efficiency and privacy.

HTLCs can facilitate cryptographic escrow for real-world agreements. Funds are locked until a specific condition, proven by revealing a secret, is met.

• Use Cases:
  • Betting Oracles: Two parties lock funds, and the outcome (provided by an oracle) determines the secret.
  • Data Feeds: Payment for a private data set, where the decryption key is the secret.
  • Adversarial Collaboration: Ensuring all parties in a multi-step process fulfill their obligations.

While powerful, HTLCs have specific constraints and risks that dictate their practical use.

• Liquidity Requirements: For routing, each channel must have sufficient locked liquidity.
• Timing Attacks: Careful time-lock scheduling is critical to prevent theft via griefing or race conditions.
• On-Chain Cost: Settling or disputing an HTLC on-chain requires a transaction, which can be expensive.
• Privacy: The hash can be observed on-chain, potentially linking transactions in a payment route.

The timelock is the contract's primary security mechanism, but its expiry creates a critical failure mode. If the payment recipient fails to provide the preimage before the timelock expires, the funds are refunded to the sender. This introduces liquidity lockup and potential price volatility risk for the duration of the lock. Mismatched timelocks across different blockchains in a cross-chain swap can lead to one party being able to claim funds while the other cannot.

The security of an HTLC hinges on the cryptographic strength of the hash function (e.g., SHA-256) and the secrecy of the preimage. If the preimage is discovered by any party before the conditional payment is initiated, the security fails. While theoretically secure, the use of weak hash functions or flawed random number generation for the preimage could make it vulnerable to brute-force attacks. The protocol assumes hash collisions are computationally infeasible.

HTLC execution is subject to underlying blockchain performance. To claim funds before the timelock expires, a transaction revealing the preimage must be confirmed on-chain. During periods of high network congestion, rising transaction fees or slow block times could prevent timely settlement, causing the claim transaction to fail and the funds to be refunded. This makes HTLCs unreliable in volatile fee environments without careful fee estimation.

In multi-hop payment networks like the Lightning Network, HTLCs are chained together. This introduces an intermediary risk. While each HTLC is individually trustless, the entire path relies on each intermediary node to forward the preimage honestly and in a timely manner. A malicious or offline intermediary can cause the payment to fail, though it cannot steal funds. This requires robust node reputation systems and pathfinding algorithms.

HTLCs are designed for a single, binary condition: "reveal the preimage." They cannot encode complex logic (e.g., multi-signature approvals, oracle data). Managing many concurrent HTLCs, especially with varying timelocks, increases state management complexity for nodes and wallets. This can lead to resource exhaustion attacks if an attacker initiates many HTLCs that a node must track until expiry.

When used for atomic swaps between different blockchains, HTLCs require careful coordination of timelocks to account for differing block times and finality rules. The slower chain dictates the minimum safe timelock for the faster chain. This results in long lockup periods (often hours or days) to ensure security, reducing capital efficiency and increasing exposure to market risk during the swap period.

The cryptographic secret that controls the release of funds in an HTLC. It is the original data that, when hashed, produces the hash lock (the public hash) specified in the contract. Revealing this preimage is the condition to unlock the funds.

• Mechanism: The payer generates a random secret (R) and computes its hash, H = hash(R). H is published in the HTLC. The payee can only claim the funds by presenting R, which proves they know the secret.
• Security: The one-way nature of the hash function (e.g., SHA-256) ensures that H cannot be reversed to find R, making the lock secure until the secret is voluntarily revealed.

A condition in a smart contract or transaction that prevents funds from being spent until (or after) a specific block height or timestamp is reached. In an HTLC, it works in tandem with the hash lock to create a secure, time-bound escrow.

• Two Types: Absolute timelocks (e.g., nLockTime in Bitcoin) specify a future time. Relative timelocks (e.g., CHECKSEQUENCEVERIFY) specify a delay relative to a previous event.
• HTLC Function: Provides a refund safety mechanism. If the hash lock condition (revealing the preimage) is not met before the timelock expires, the funds can be reclaimed by the original sender, preventing them from being locked indefinitely.

A protocol that enables the transfer of assets and data between independent blockchains. Many bridge designs utilize HTLCs for their atomicity and trust-minimized properties, especially in models without a centralized custodian.

• HTLC-based Bridge Flow: To move an asset from Chain A to Chain B, the user locks funds in an HTLC on Chain A. A bridge validator or relayer, upon seeing this lock, creates/mints a wrapped asset on Chain B. The user reveals the preimage to claim the wrapped asset, which the relayer then uses to unlock and claim the original funds on Chain A.
• Alternative to Custody: Reduces reliance on a single trusted entity holding all user funds.

A broad class of financial transactions where the transfer of value depends on the fulfillment of a predefined condition. An HTLC is a specific, cryptographically-enforced implementation of a conditional payment.

• Core Logic: The condition is the presentation of a cryptographic secret (preimage). This model can be generalized for other oracles or data feeds.
• Extended Applications: While HTLCs use a hash condition, the concept extends to payments conditional on real-world events (via oracles), the outcome of a game, or the completion of a service, forming the basis for more complex smart contracts.