OP_CHECKSEQUENCEVERIFY (CSV)
Also called: CSV, OP_CSV, CHECKSEQUENCEVERIFY, OP_NOP3, BIP 112, relative timelock.
OP_CHECKSEQUENCEVERIFY (CSV, BIP 112) is an opcode that blocks spending an output until it has aged a set number of blocks or time since it confirmed.
OP_CHECKSEQUENCEVERIFY (CSV) is a Bitcoin Script opcode for relative timelocks: it stops an output being spent until a certain number of blocks, or amount of time, has passed since that output confirmed. It is defined in BIP 112 by BtcDrak, Mark Friedenbach and Eric Lombrozo, redefines OP_NOP3 (0xb2), and activated at block 419,328 in July 2016 together with BIP 68 and BIP 113.
How CSV works
BIP 68 gave each input's nSequence field a consensus meaning in transactions with version 2 or higher:
- bit 31 set: no relative lock;
- bit 22 set: the value counts units of 512 seconds, otherwise blocks;
- the low 16 bits hold the value (up to 65,535), enough for roughly a year.
CSV compares the number on the stack with the input's nSequence. Unless the stack value has its own disable bit set, the script fails if the transaction version is below 2, the input's disable bit is set, the two use different units, or the stack value is larger. Because BIP 68 already stops the transaction from being mined until the input is old enough, CSV turns that into a condition on the coins themselves:
144 OP_CHECKSEQUENCEVERIFY OP_DROP <pubkey> OP_CHECKSIG
This output can be spent about one day (144 blocks) after it confirms.
Why CSV matters
Relative timelocks let a contract say "you have N blocks to react after this transaction appears" without knowing in advance when it will confirm. Lightning channels put a CSV delay on each party's own balance so the other side can punish a cheating close, and vault designs use it for withdrawal delays. Compare it with absolute locks in BIP 65 vs BIP 112.