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: the coins cannot be spent until the blockchain reaches a specified height or time. It redefined the previously unused OP_NOP2, so it activated as a soft fork in 2015 without breaking older nodes — to legacy software the opcode still looks like a harmless no-op, while upgraded nodes enforce the constraint. CLTV is the script primitive behind escrow refunds, payment-channel timeouts, inheritance schemes, 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 (which would disable lock-time checking entirely). 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 — you cannot compare a height against a timestamp. 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, which is why scripts conventionally follow it with OP_DROP. The elegance of the design is that the opcode never consults a clock itself — it only constrains nLockTime, and the existing consensus rule that a transaction with a future nLockTime cannot be mined does the actual waiting.

Why it matters

Before CLTV, a coin could only be timelocked at the transaction level, which the holder of the keys could simply bypass by signing a different transaction. 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. That guarantee is a building block for trust-minimized contracts where one party must be able to reclaim funds after a deadline: the original Lightning Network HTLC constructions used exactly this shape — pay with a secret now, or refund to the sender after the timeout — and unidirectional payment channels, escrows, and dead-man-switch inheritance wallets all reduce to the same "spendable by A now under conditions, by B after time T" pattern, often combined with multisig branches.

Wallet support for CLTV-based timelocks has matured well beyond hand-rolled scripts: descriptor-based tooling and miniscript let these conditions be expressed, backed up, and restored without bespoke code, moving timelocked custody from developer trick to practical option.

On the sovereignty bench

CLTV is one of the few pieces of financial machinery an individual can operate with no institution involved: a self-custodied inheritance plan, a vault that refuses to move before a date you chose, a recovery path that activates only if you go silent — all enforced by every node on the network rather than by a trustee. It is a modest opcode with a radical property: time itself becomes a spending condition that no one can waive. As with all pre-signed, time-sensitive constructions, plan the fees for the far-future spend carefully; the network conditions at unlock time are not knowable at lock time.

CLTV handles absolute deadlines; for "N blocks after this output confirms" logic, see OP_CHECKSEQUENCEVERIFY (CSV), its relative-timelock sibling. Both are commonly embedded inside a Pay-to-Script-Hash (P2SH) or SegWit script to keep the funding output compact, and both are stepping stones toward the richer spending constraints discussed under covenants.