Hash Time-Locked Contract (HTLC)

The hashlock is a cryptographic condition that locks funds. The sender creates a preimage (secret data) and publishes its cryptographic hash. Funds can only be claimed by any party who reveals this preimage, proving they know the secret. This creates a verifiable, one-way condition for payment release.

• Example: Alice locks 1 BTC with hash H. Bob can only claim it by providing the secret R where hash(R) = H.

The timelock is a safety mechanism that sets an expiration for the conditional payment. It is enforced via a blockchain's native scripting (e.g., OP_CHECKLOCKTIMEVERIFY in Bitcoin). If the correct preimage is not revealed before the timelock expires, the funds are automatically refunded to the original sender.

• Prevents Fund Loss: Guarantees the sender's capital is not locked indefinitely if the counterparty fails to act.

HTLCs enable atomic swaps between different blockchains without a trusted third party. Two parties create mirrored HTLCs on two separate chains (e.g., Bitcoin and Ethereum), linked by the same hashlock. The revelation of the preimage to claim funds on one chain automatically reveals it to claim funds on the other, making the swap all-or-nothing.

• Key Property: The swap is atomic; it either completes entirely for both parties or fails entirely, eliminating counterparty risk.

HTLCs are the backbone of Layer 2 payment channels like the Lightning Network. They allow secure, multi-hop payments where intermediaries can forward funds without needing to trust the sender or receiver. Each hop in the route is secured by its own HTLC, with decrementing timelocks to ensure forward progress.

• Enables Scalability: Transactions are settled off-chain, with the blockchain acting as a final settlement and dispute layer.

An HTLC acts as a cryptographic escrow that does not require a trusted custodian. The contract's logic, enforced by the blockchain's consensus rules, dictates exactly how and when funds can be disbursed. This reduces reliance on intermediaries and enables decentralized finance (DeFi) applications like cross-chain bridges and atomic DEX trades.

HTLCs are implemented using a blockchain's native smart contract or scripting language. In Bitcoin, this is a Bitcoin Script combining OP_SHA256, OP_EQUAL, and OP_CHECKLOCKTIMEVERIFY. In Ethereum, it's a Solidity contract. The script defines the two possible spending paths: one with the correct preimage, and one with a valid refund after the timelock.

An HTLC locks funds with two conditions:

• Cryptographic Lock: The payer generates a secret and shares only its hash. The recipient must reveal the original secret to claim the funds.
• Time Lock: A refund clause. If the secret is not revealed before a specified block height or timestamp, the funds are returned to the payer. This creates a trust-minimized conditional transfer, ensuring atomicity—either both legs of a swap succeed or both fail.

HTLCs are the foundational protocol for trustless cross-chain asset swaps without centralized intermediaries. Process:

1. Alice locks Bitcoin in an HTLC on its blockchain, using a secret hash.
2. Bob, seeing the lock, locks an equivalent amount of Litecoin in a corresponding HTLC on its chain, using the same hash.
3. Alice reveals the secret to claim Bob's Litecoin.
4. Bob uses the now-public secret to claim Alice's Bitcoin. This enables direct peer-to-peer trading between disparate blockchains like Bitcoin and Litecoin.

HTLCs are the building blocks of bidirectional payment channels in the Lightning Network and similar Layer 2 systems. How it works:

• Payments are routed across a network of channels via HTLC forwarding.
• Each hop in the path creates an HTLC, with decreasing time locks.
• The final recipient reveals the secret, which propagates backwards, allowing each intermediary to claim funds from the preceding hop. This enables instant, high-throughput micropayments secured by the underlying blockchain's finality.

While modern bridges often use more complex architectures, early and simpler bridge designs relied on HTLCs for cross-chain asset transfers. Example Flow:

1. A user locks Asset A on Chain A in an HTLC.
2. A bridge validator or watchtower observes this event.
3. Upon confirmation, an equivalent amount of a wrapped Asset A is minted on Chain B and sent to the user. The time lock ensures the bridge operator has a bounded timeframe to act, reducing certain risks.

HTLCs introduce specific security parameters that must be carefully configured:

• Time Lock Granularity: Must account for block time variance and network congestion. Too short risks failing legitimate swaps; too long increases capital lockup and exposure.
• Hash Collision Attacks: While cryptographically improbable, the hash function (e.g., SHA-256) must be secure.
• Fee Management: In routed payments, fees must be embedded, and time locks must accommodate potential transaction replacement or fee bumping.

A simplified version of a Bitcoin Script for an HTLC showcases its logic:

codeCopy
OP_IF
    [HASHOP] <hash> OP_EQUALVERIFY
    <Recipient's PubKey> OP_CHECKSIG
OP_ELSE
    <Timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <Sender's PubKey> OP_CHECKSIG
OP_ENDIF

Interpretation:

• The IF branch allows the recipient to claim with the correct secret and signature.
• The ELSE branch allows the sender to refund after the CHECKLOCKTIMEVERIFY timeout passes.

The timelock is a critical parameter that creates a race condition. If the secret is revealed late in the process, the counterparty may have a narrow window to claim their funds before the timelock expires, allowing the original sender to refund. Poorly synchronized blockchains or network congestion can exacerbate this risk.

• Setting the Locktime: Too short risks the recipient; too long locks capital unnecessarily.
• Blockchain Finality: On chains with probabilistic finality, a refund transaction might be reversed if a secret-revealing transaction is later reorged out.

A malicious participant can initiate an HTLC without ever intending to fulfill it, locking the counterparty's capital for the duration of the timelock. This griefing attack is a form of economic denial-of-service.

• Cost: The attacker only loses the transaction fee to initiate the lock, while the victim's capital is immobilized.
• Amplification: In multi-hop payment channels (e.g., the Lightning Network), a single failed HTLC can stall funds across multiple nodes.

Bugs in the smart contract code for the HTLC (on chains like Ethereum) or in the protocol logic (in Layer-2 networks) can lead to loss of funds. Furthermore, cross-chain HTLCs often rely on external oracles or relayers to verify proofs, introducing a trust assumption.

• Smart Contract Vulnerabilities: Reentrancy, integer overflow, or incorrect timelock logic.
• Oracle Manipulation: A compromised oracle could falsely attest to a secret reveal or timelock expiry.

Successfully claiming funds from an HTLC requires broadcasting a transaction to the blockchain. During periods of high network congestion, participants must outbid others for block space. Transaction malleability (historically on Bitcoin) could change a transaction's ID, potentially breaking the script's spending conditions.

• Claim Priority: A refund transaction with a higher fee might be mined before the legitimate claim.
• Malleability Fixes: SegWit (Bitcoin) and specific smart contract patterns mitigate this historical issue.

The hash H is public on-chain. If the same hash is reused across multiple HTLCs, it creates a correlation vector that can link seemingly unrelated transactions. This is a significant privacy concern in networks like the Lightning Network, where payment correlation can reveal the network topology and payment routes.

• Pattern Analysis: Observers can track the flow of a specific hash to map channel balances and relationships.
• Solution: Modern protocols use point-time-locked contracts (PTLCs) with adaptor signatures to avoid this leakage.

While powerful, HTLCs have inherent constraints that shape their application:

• Liquidity Requirements: For routing payments (e.g., Lightning), nodes must have sufficient locked capital in their channels, creating capital efficiency challenges.
• Routing Complexity: Finding a path with adequate liquidity and favorable fees across a decentralized network is a non-trivial problem.
• Timelock Management: Mismatched or poorly set timelocks can lead to funds being stuck or vulnerable. The entire route must use decrementing timelocks to prevent theft.
• Privacy Leakage: The hash value is public, allowing network observers to correlate payments across different hops in a route.

The HTLC pattern can be adapted for oracle services, where data delivery is conditional on proof.

• Example: A smart contract offers a reward for providing a specific data point (e.g., a sports score). The reward is locked in an HTLC. The first oracle to submit the correct data, which hashes to the predefined value, can claim the reward by revealing the data as the secret.
• Use Case: This creates a simple, trust-minimized bounty system for data feeds, though it is less common than dedicated oracle networks like Chainlink for complex, frequent data.

A peer-to-peer cryptocurrency exchange between two different blockchains executed without a trusted third party. It is the primary application of an HTLC.

• Mechanism: Both parties create HTLCs on their respective chains, locking funds with the same cryptographic hash and time constraints.
• Outcome: The swap either completes atomically when the secret is revealed, or funds are refunded after the timelock expires, preventing one-sided risk.

A Layer 2 payment protocol built on Bitcoin (and other blockchains) that uses bidirectional payment channels secured by HTLCs for instant, high-volume micropayments.

• Role of HTLCs: Enables secure multi-hop payments across a network of channels. Each intermediary node uses an HTLC to forward payments conditionally, ensuring they are only committed if the entire path is viable.

The two-part locking mechanism at the core of an HTLC.

• Hashlock: A cryptographic condition requiring the presentation of the preimage (secret data) that hashes to a specified public hash (H). This ensures payment is conditional on proof of a secret.
• Timelock: A time-based condition (e.g., a block height) after which the locked funds can be claimed by a refund transaction. This enforces a deadline and prevents funds from being locked indefinitely.

Protocols that enable the transfer of assets and data between different blockchain networks. Many bridges utilize HTLCs for simple, non-custodial asset swaps.

• HTLC Model: A user locks Asset A on Chain 1 in an HTLC. A relay or watcher observes this, and a corresponding HTLC for Asset B is created on Chain 2. The user reveals the secret to claim Asset B, which also allows the bridge to claim Asset A, completing the cross-chain transfer.

A mechanism where two parties lock funds in a shared multisignature address to conduct numerous off-chain transactions, settling the net result on the blockchain. HTLCs are used to extend functionality beyond the two direct participants.

• Key Function: HTLCs allow for conditional payments through a payment channel, enabling the construction of networks like the Lightning Network without requiring direct channels between all parties.

A one-way mathematical function (e.g., SHA-256) that is essential for creating the hashlock condition in an HTLC.

• Properties Used:
  • Preimage Resistance: Given a hash output H, it is computationally infeasible to find the input preimage R.
  • Determinism: The same input R always produces the same hash H.
• Example: In Bitcoin HTLCs, the hash H is placed in the locking script, and the spending transaction must provide the preimage R that hashes to H.