OP_CHECKLOCKTIMEVERIFY (OP_CLTV)

What Is OP_CHECKLOCKTIMEVERIFY?

OP_CHECKLOCKTIMEVERIFY (commonly abbreviated OP_CLTV) is a Bitcoin consensus opcode that creates absolute timelocks on transaction outputs. When included in a script, it guarantees that the output cannot be spent until a specified point in time: either a particular block height or a Unix timestamp. Any transaction that attempts to spend the output before that point is invalid and will be rejected by the network.

OP_CLTV was introduced in BIP 65, authored by Peter Todd, and activated on Bitcoin mainnet at block 388,381 on December 14, 2015. It replaced the previously unused OP_NOP2 opcode (opcode number 177 / 0xb1), making the upgrade a soft fork: older nodes that had not upgraded simply treated the byte as a harmless no-op, while upgraded nodes enforced the new timelock semantics.

Before OP_CLTV, Bitcoin's nLockTime field could restrict when a transaction was valid, but there was no way to restrict when a specific output could be spent at the script level. OP_CLTV bridges this gap, enabling scripts that encode time-based spending conditions directly into the output.

How It Works

OP_CLTV reads the top value from the script stack and compares it against the nLockTime field of the transaction attempting to spend the output. The opcode does not consume the stack value: it remains on the stack after execution (which is why scripts typically follow OP_CLTV with OP_DROP).

The opcode performs four sequential checks. If any check fails, the script terminates and the transaction is invalid:

1. The stack must not be empty, and the top value must not be negative
2. The stack value and the transaction's nLockTime must be the same type: both must be block heights (values below 500,000,000) or both must be Unix timestamps (values at or above 500,000,000). Mixing types causes the script to fail.
3. The transaction's nLockTime must be greater than or equal to the stack value. In other words, the transaction must declare a lock time at least as far in the future as the script requires.
4. The spending input's nSequence must not be 0xFFFFFFFF, because that value disables nLockTime for the input entirely.

The 500,000,000 Threshold

Bitcoin uses a single nLockTime field for two distinct purposes, distinguished by the LOCKTIME_THRESHOLD constant of 500,000,000:

• Values below 500,000,000 are interpreted as block heights (e.g., 900000 means "not spendable until block 900,000")
• Values at or above 500,000,000 are interpreted as Unix timestamps in seconds since the epoch (e.g., 1750000000 means "not spendable until approximately June 2025")

OP_CLTV enforces that both the script's required value and the transaction's nLockTime use the same interpretation. You cannot lock an output to a block height and then spend it with a timestamp-based nLockTime, or vice versa.

Script Example

A basic time-locked output script that prevents spending until block 900,000:

# ScriptPubKey (locking script)
900000 OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

# To spend, the transaction must set:
#   nLockTime >= 900000
#   nSequence != 0xFFFFFFFF

The OP_DROP following OP_CLTV removes the lock time value from the stack so the remaining script (a standard P2PKH check) can execute cleanly.

OP_CLTV vs OP_CSV

Bitcoin has two timelock opcodes that serve complementary purposes. OP_CHECKSEQUENCEVERIFY (OP_CSV), defined in BIP 112 and activated in May 2016, enforces relative timelocks rather than absolute ones.

The distinction matters in practice: OP_CLTV sets a fixed deadline that never changes, regardless of when the UTXO was created. OP_CSV starts its timer when the UTXO is confirmed on-chain, making it ideal for protocols like payment channels where the clock should begin ticking only after a specific transaction confirms. Many protocols use both opcodes together, leveraging CLTV for payment expiry and CSV for revocation delays.

For a detailed comparison of both opcodes and their protocol interactions, see the research article on Bitcoin timelocks: CLTV and CSV.

Use Cases

Time-Locked Savings

OP_CLTV enables provably unspendable funds until a chosen date: a form of enforced HODLing. A user can send Bitcoin to a script that locks the output until a future block height, making it impossible to spend prematurely even if the private key is compromised. This pattern is useful for long-term savings, vesting schedules, or cold storage with time-based access controls.

HTLC Refund Paths

Hashed Time-Locked Contracts are the core mechanism behind Lightning Network payments and cross-chain atomic swaps. Every HTLC has two spending paths:

• The hashlock path: the recipient claims funds by revealing a preimage that hashes to the payment hash
• The timelock path: the sender reclaims funds after the OP_CLTV expiry if the recipient never reveals the preimage

Without OP_CLTV, there would be no trustless way to guarantee that a sender can recover their funds from an unclaimed HTLC. The absolute timelock ensures that after a fixed block height, the refund path becomes available regardless of the recipient's cooperation.

Inheritance and Dead Man's Switch

OP_CLTV can construct scripts where an heir's key becomes valid after a prolonged period. The owner periodically moves funds to a new UTXO with a fresh lock time, resetting the deadline. If the owner stops refreshing (due to death or incapacitation), the heir can eventually claim the funds once the timelock expires. For dead man's switch patterns where the timer resets automatically on each spend, OP_CSV (relative timelocks) is often preferred.

Escrow with Timeout

OP_CLTV enables multi-party escrow scripts that include a timeout fallback. For example, a 2-of-2 multisig between a buyer and seller can include a third-party arbitrator key that activates only after a CLTV expiry. If the primary parties cannot agree, the arbitrator can step in after the timeout to resolve the dispute.

IF
  <expiry_time> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <arbitrator_pubkey> OP_CHECKSIGVERIFY
  1
ELSE
  2
ENDIF
<buyer_pubkey> <seller_pubkey> 2 OP_CHECKMULTISIG

Role in Lightning Network Security

OP_CLTV is fundamental to the Lightning Network's routing security. In a multi-hop payment, each HTLC along the route carries an absolute block height expiry enforced by OP_CLTV. These expiry values decrease at each hop: the sender's HTLC expires later than the next node's, which expires later than the next, and so on to the final recipient.

This decreasing chain of timelocks ensures safety. Each routing node has a buffer of blocks (the cltv_expiry_delta, typically 40 blocks or roughly 6.7 hours) between when its outgoing HTLC expires and when its incoming HTLC expires. If a downstream node settles an HTLC on-chain at the last possible moment, the routing node still has enough time to claim its incoming HTLC before that one expires.

Without OP_CLTV enforcing these absolute deadlines, a malicious node could hold an HTLC indefinitely, locking up liquidity across the entire route. The timelock guarantees that funds always return to the sender if payment fails, making trustless multi-hop routing possible. Complementing this, OP_CSV handles the separate concern of revocation delays after a force-close, giving watchtowers time to detect and penalize cheating attempts via justice transactions.

Why It Matters

OP_CLTV transformed Bitcoin from a system with only transaction-level timelocks into one with output-level time constraints embedded directly in Script. This distinction is critical: before BIP 65, the nLockTime field could delay when a transaction was valid, but nothing prevented an output from being spent by a different, non-timelocked transaction. OP_CLTV closes that gap by making the timelock a property of the spending condition itself.

This capability unlocked an entire class of trustless protocols. HTLCs, which depend on OP_CLTV for their refund mechanism, are the foundation of the Lightning Network, atomic swaps, and submarine swaps. Layer 2 protocols like Spark also benefit from the broader ecosystem of timelock-based constructions that OP_CLTV enabled, as timelocks are a core primitive for securing off-chain state transitions and ensuring users can always recover their funds on-chain.

Risks and Considerations

Irreversible Lock Periods

Once funds are sent to a CLTV-locked output, there is no way to spend them before the specified time, even if circumstances change. A script that locks funds until block 1,000,000 is absolute: no key, signature, or protocol upgrade can override the timelock. Users must carefully choose lock times and understand that mistakes (such as locking funds to a block height decades in the future) are permanent.

Clock Skew with Timestamps

When using Unix timestamps rather than block heights, the effective unlock time depends on miners' block timestamps, which are permitted to deviate from real-world time within certain bounds. The median time past (MTP) rule means the actual unlock time may differ from the wall-clock expectation by up to a few hours. For precision-sensitive applications, block heights are generally more predictable than timestamps.

Transaction Size Overhead

OP_CLTV adds bytes to the script: typically 4-5 bytes for the lock time value, plus 1 byte for the opcode and 1 byte for OP_DROP. In standard single-condition scripts this overhead is minimal, but in complex scripts with multiple branches and timelocks, it contributes to larger transaction sizes and higher fees. Modern constructions using Taproot and Miniscript can mitigate this by hiding unused script branches.

No Cancellation Mechanism

OP_CLTV is a one-way constraint: it can enforce a minimum time before spending but cannot impose a maximum. There is no native "spend only before block N" opcode in Bitcoin. Protocols that need expiry windows (spend between time A and time B) must implement the upper bound through other means, such as pre-signed transactions or relative timelocks with OP_CSV.

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.