Hashed Timelock Contract (HTLC)

The hashlock is based on a secret and its calculated hash, and the recipient proves knowledge of the secret by revealing a preimage that produces the agreed hash. This is not a process of decrypting the hash or supplying a password that is automatically the same as a private signing key.

Signatures can also be required, so knowing the preimage alone does not necessarily authorise every person to spend the funds, and the script can identify who may use the claim path and who may use the refund path. The timelock creates a defined fallback, since a payment need not remain locked forever if the intended recipient never claims it, and the refund condition and the type of timeout must be understood before funds are committed.

Timeouts can be expressed through relevant blockchain mechanisms, but a block-based condition does not necessarily correspond to a precise wall-clock instant because block timing varies. Operational planning should leave room for confirmation and settlement delays.

BIP 199 describes an HTLC script in which a designated party can spend funds by revealing a hash preimage and another party can spend after a timeout in a refund situation. It is a technical proposal, not evidence that every network or wallet has adopted the same feature, so the actual implementation determines available operations.

Revealing the secret can connect multiple conditional payments, because in an atomic-swap design information disclosed while claiming one payment can permit the counterparty to claim another, which makes the relationship between the contracts and their deadlines central to the design. An atomic arrangement aims to avoid one party receiving value while the other cannot complete the corresponding leg, but it does not remove every risk, since incorrect amounts, wrong destinations, incompatible scripts or poor deadline choices can still create loss or failed execution.

Lightning-style payment routes can also use hash-and-time conditions, and several linked channels can support a payment without treating every participant as an unconditional lender, although the route's protocol and implementation add requirements beyond a simple two-party script example. Deadline ordering matters when more than one contract is involved, because one leg may need an earlier claim window so the other party has time to act after learning the secret, and equal deadlines are not automatically the safest design.

Network fees and monitoring remain relevant, since a claim or refund may require a transaction to be submitted and confirmed. An available legal or script path is not the same as an operation already completed on the ledger.