OP_CHECKLOCKTIMEVERIFY (CLTV)

OP_CHECKLOCKTIMEVERIFY, abbreviated CLTV, is a Bitcoin Script opcode introduced in BIP 65 that lets a locking script enforce an absolute timelock at the script level. It redefined the previously unused OP_NOP2, so it activated as a soft fork without breaking older nodes. CLTV is the script primitive behind escrow refunds, payment-channel timeouts, and time-locked vaults.

How CLTV evaluates

CLTV compares the value on top of the stack against the spending transaction's nLockTime field. Execution fails (the spend is rejected) if the stack is empty, the top item is negative, the lock-time types do not match, the stack value is greater than nLockTime, or the input's nSequence equals 0xffffffff. The 500,000,000 threshold decides interpretation: values below it are block heights, values at or above it are Unix timestamps, and both operands must use the same type. Crucially, CLTV does not pop its argument off the stack — it behaves like a NOP that simply aborts if the condition is unmet, leaving the value in place for subsequent opcodes.

Why it matters

Before CLTV, a coin could only be timelocked at the transaction level, which a spender could alter. By embedding the constraint inside the scriptPubKey, the sender guarantees the output cannot be moved until the chain reaches a chosen height or time, regardless of who spends it. This makes CLTV a building block for trust-minimized contracts where one party must be able to reclaim funds after a deadline.

CLTV handles absolute deadlines; for “N blocks after this output confirms” logic, see OP_CHECKSEQUENCEVERIFY (CSV). Both are commonly embedded inside a Pay-to-Script-Hash (P2SH) output to keep the funding script compact.