OP_CHECKLOCKTIMEVERIFY

A timelock written into the coin rather than into the transaction that spends it. Peter Todd specified it in BIP65, where it took over the slot of the old no-op opcode NOP2, and the rule has been enforced since block 388,381 in December 2015. If you have ever set up an inheritance plan or a recovery path, this opcode is the thing holding the door shut.

How it works

OP_CHECKLOCKTIMEVERIFY reads one number from the script stack, compares it against the locktime field of the transaction trying to spend the coin, and aborts the whole script if the spend is early.

BIP65 lists five ways the check fails: the stack is empty, the top item is negative, the item and the transaction's locktime disagree about whether they are counting blocks or counting seconds, the item is larger than the transaction's locktime, or the input's sequence number is set to 0xffffffff. That last condition closes an obvious hole. A locktime is ignored entirely when every input is marked final, so without it a spender could simply switch the deadline off and walk away with the money.

Two details surprise people reading such a script for the first time. The opcode does not consume the number it checks, so real scripts follow it with OP_DROP to tidy the stack. And it accepts a five byte operand rather than the usual four, because the largest value it may have to compare against is 2**32-1, the full range of the field it is checking.

The soft fork mechanics were the ordinary kind. Redefining a no-op is invisible to software that has not been upgraded: an old node runs the opcode, does nothing, and accepts the block anyway. Activation used the miner signalling thresholds of the day, 750 blocks in 1,000 to begin enforcement and 950 in 1,000 to make it mandatory.

Where you see it

OP_CHECKLOCKTIMEVERIFY turns up wherever money has to sit still until a date arrives.

Inheritance and recovery wallets are the clearest case. A descriptor can say that your own key spends at any time while a backup key spends only after a stated height, which gives an heir a path that needs no cooperation from anyone and no lawyer holding a sealed envelope. Miniscript writes this as the after() fragment, and wallets that support it show you the height in plain language instead of raw script.

Lightning uses it for the absolute deadline on a routed payment. A BOLT11 invoice carries a final expiry delta, 18 blocks by default, and the hashed contracts along the route are stacked above that figure so each hop can reclaim its funds in a fixed order if the payment never completes.

Escrow and trustless refunds follow the same shape: pay into a script now, and if the counterparty never signs, take the money back once the deadline passes. The opcode is also the honest answer to anyone selling a "time locked vault" as a product, because this is all such a product can be.

OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY names a moment; OP_CHECKSEQUENCEVERIFY names a duration. One says "not before December", the other says "not until 144 blocks after this particular coin confirmed", and only the second starts its clock when the coin lands. BIP112 defined the relative form and it activated at block 419,328 in July 2016, roughly seven months after its absolute sibling. Contract protocols use both, often in one script: an absolute deadline to bound the whole agreement, and a relative delay to guarantee one party a window in which to react.