Timelock

What Is a Timelock?

A timelock is a restriction embedded in a Bitcoin transaction or script that prevents an output from being spent until a certain condition related to time is satisfied. Think of it like a safe with a timer: the funds exist and are assigned to you, but you cannot access them until the clock runs out.

Timelocks were introduced to Bitcoin in stages. The original nLockTime field has existed since the earliest versions of the protocol, but it was limited in usefulness because it only constrained when a transaction could be broadcast, not when an output could be spent. Two later upgrades added script-level timelocks that are enforced by consensus: OP_CHECKLOCKTIMEVERIFY (CLTV, activated in BIP 65) and OP_CHECKSEQUENCEVERIFY (CSV, activated in BIP 112). Together, these opcodes enable the time-based logic that powers payment channels, atomic swaps, and the broader Lightning Network.

How It Works

Bitcoin timelocks operate at two levels: the transaction level and the script level. The transaction-level nLockTime field sets the earliest time a transaction can be included in a block, but miners are not obligated to enforce it on outputs. Script-level timelocks, by contrast, are enforced by every validating node on the network.

Absolute Timelocks: OP_CHECKLOCKTIMEVERIFY (CLTV)

CLTV creates an absolute deadline. It compares the value on the stack against the spending transaction's nLockTime field and fails the script if the locktime has not been reached. This means the UTXO cannot be spent in any block before that height or timestamp.

The locking value is interpreted in one of two ways depending on its magnitude:

• Values below 500,000,000 are interpreted as block heights. For example, a CLTV value of 850,000 means the output cannot be spent until block 850,000 is mined.
• Values of 500,000,000 or above are interpreted as Unix timestamps. A value of 1,700,000,000 means the output cannot be spent until that moment in time (as determined by the block's median time past).

A typical CLTV script in Bitcoin Script looks like this:

OP_IF
  # Cooperative path: both parties can spend anytime
  <pubkey_A> OP_CHECKSIGVERIFY
  <pubkey_B> OP_CHECKSIG
OP_ELSE
  # Timelock path: only party A can spend after block 850000
  850000 OP_CHECKLOCKTIMEVERIFY OP_DROP
  <pubkey_A> OP_CHECKSIG
OP_ENDIF

In this example, both parties can cooperate to spend the output at any time. But if cooperation fails, party A can unilaterally claim the funds after block 850,000. This pattern appears throughout Lightning Network channel constructions.

Relative Timelocks: OP_CHECKSEQUENCEVERIFY (CSV)

CSV creates a relative delay. Instead of locking funds until a fixed point in time, it locks them for a certain number of blocks (or a duration measured in 512-second increments) after the output being spent was confirmed on chain. The countdown starts when the parent transaction is mined, not from any fixed reference point.

CSV uses the transaction's nSequence field for enforcement:

• If bit 22 is not set, the value is interpreted as a number of blocks. A CSV value of 144 means the output cannot be spent until 144 blocks (roughly one day) after confirmation.
• If bit 22 is set, the remaining bits encode time in 512-second granularity. This allows relative delays measured in real time rather than block count.

# Relative timelock: must wait 144 blocks after confirmation
144 OP_CHECKSEQUENCEVERIFY OP_DROP
<pubkey> OP_CHECKSIG

Relative timelocks are essential to Lightning because they allow channel constructions where the penalty window is always a fixed duration after a breach attempt, regardless of when that attempt occurs.

Block Height vs. Timestamp Locking

Both CLTV and CSV can lock by block count or by time, but a script cannot mix the two. If the CLTV value is a block height, the spending transaction's nLockTime must also be a block height (below 500,000,000). Similarly, timestamp-based locks require timestamp-based nLockTime values.

Block height locking is generally preferred for protocol constructions because block production is more predictable for short durations than wall-clock time. The Bitcoin network adjusts difficulty to target 10-minute blocks, but actual intervals vary. Timestamp locking uses "median time past" (the median of the last 11 blocks' timestamps) rather than real-world clock time, which adds a layer of imprecision.

Use Cases

Hash Time-Locked Contracts (HTLCs)

HTLCs combine timelocks with hash locks to create conditional payments. The receiver must reveal a preimage matching a payment hash before the timelock expires. If they fail to do so, the sender reclaims the funds after the timeout.

In a multi-hop Lightning payment, each node along the route uses a decreasing CLTV value. If the final recipient has a CLTV expiry at block 850,100, the previous hop might use 850,140, and the hop before that 850,180. This staggered structure ensures each node has enough time to claim their incoming HTLC after settling the outgoing one. The difference between hops is called the timelock delta (or cltv_expiry_delta), and it is advertised by each node in its channel announcements.

Payment Channels and Force-Close

Lightning channels use relative timelocks (CSV) to create a dispute window during unilateral closes. When one party broadcasts a commitment transaction to close a channel, the broadcaster's output is locked by a CSV delay (commonly 144 blocks, or roughly one day). This gives the counterparty time to check whether the broadcasted state is outdated.

If the counterparty detects a stale commitment, they can broadcast a justice transaction that claims all channel funds using the revocation key for that old state. A watchtower can perform this check on behalf of offline users. Without the CSV-enforced delay, there would be no time for this fraud proof.

During a force-close, the party who initiated the close must wait for the CSV delay before accessing their funds. The counterparty's non-delayed output is available immediately, and any pending HTLCs resolve on their own timelock schedule. Anchor outputs allow either party to fee-bump the commitment transaction during this waiting period, an important consideration given Bitcoin fee market dynamics.

Inheritance and Dead Man's Switch

Timelocks enable inheritance schemes without trusted third parties. A user can construct a script where their heirs can spend funds after a long absolute timelock (say, one year into the future). The user periodically refreshes the timelock by moving funds to a new output with an updated expiry. If the user becomes incapacitated and stops refreshing, the heirs can eventually claim the funds.

OP_IF
  # Owner can spend anytime with their key
  <owner_pubkey> OP_CHECKSIG
OP_ELSE
  # Heir can spend after ~1 year (52,560 blocks)
  52560 OP_CHECKSEQUENCEVERIFY OP_DROP
  <heir_pubkey> OP_CHECKSIG
OP_ENDIF

Vesting and Escrow

Organizations can use timelocks to create vesting schedules for token or bitcoin distributions. Funds are locked into multiple UTXOs with staggered CLTV values, each becoming spendable at different future block heights. This provides on-chain enforcement without requiring any custodian.

Timelocks in Lightning Routing

The timelock delta is a critical parameter for Lightning routing. Each routing node advertises a cltv_expiry_delta value in its channel updates, typically between 18 and 144 blocks. This value determines how much extra CLTV buffer the node requires between its incoming and outgoing HTLCs.

Choosing the right delta involves a tradeoff:

• Larger deltas give routing nodes more time to react to on-chain events (fee spikes, chain reorgs) but make payments more expensive in terms of locked time and may cause routes to be rejected by senders who prefer shorter total timelocks.
• Smaller deltas reduce the total payment lockup time, making routes more attractive, but leave less margin for the routing node to safely settle on chain if a downstream channel must force-close.

The total CLTV across a route equals the sum of all intermediate deltas plus the final hop's expiry. For a payment traversing five hops with 40-block deltas each, the sender's HTLC might lock funds for 200+ blocks (roughly 33 hours). This cumulative lockup is one reason why shorter routes are preferred and why the Lightning Network benefits from efficient liquidity management.

Risks and Considerations

Force-Close Delays

The CSV delay during a force-close can lock funds for an extended period. Standard channel implementations use delays of 144 to 2,016 blocks (one day to two weeks). During this time, the closing party cannot use their funds. If on-chain fees are high during this window, the cost of resolving HTLCs and sweeping outputs can eat significantly into channel balances. Understanding fee market dynamics is important for anyone operating Lightning channels.

Timelock Expiry Races

When an HTLC is close to expiring, a race condition can develop. The party claiming the HTLC via preimage and the party reclaiming it via timeout may both attempt to broadcast conflicting transactions. If mempool congestion delays confirmation, the wrong party might succeed. This is why timelock deltas must include sufficient buffer to account for confirmation uncertainty, and why anchor outputs (which allow fee-bumping after broadcast) are critical for production Lightning implementations.

Timestamp Imprecision

Timestamp-based timelocks rely on median time past, which can drift from actual wall-clock time. Miners have some flexibility in the timestamps they include in blocks, and the median of 11 blocks can lag behind real time by up to two hours. For most applications this imprecision is acceptable, but protocol designers should account for it when setting timelock values.

Compatibility Constraints

Because timelocks are enforced at the consensus level, any error in constructing a timelock script can permanently lock funds. A CLTV value set to a block height far in the future, or a CSV value that exceeds the maximum allowed sequence number, will make the output unspendable until those conditions are met. There is no override mechanism. Wallet developers and protocol designers must test timelock logic carefully to avoid irreversible mistakes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.