CheckSequenceVerify (CSV)

OP_CHECKSEQUENCEVERIFY (CSV) is the Bitcoin Script opcode that enforces relative locktimes inside a script. It's the relative-timing companion to OP_CHECKLOCKTIMEVERIFY's absolute-timing.

The distinction matters:

• CLTV (absolute): "this output can be spent after block 900,000" - a specific moment.
• CSV (relative): "this output can be spent 144 blocks (~1 day) after this UTXO was confirmed" - a duration measured from when the UTXO entered the chain.

Introduced via BIP-112 (the opcode) and BIP-68 (the underlying nSequence semantics) and BIP-113 (median-time-past for time-based delays), CSV activated as a soft fork in July 2016.

Where CSV is load-bearing:

• Lightning channel close-outs. When a party force-closes a channel, their share of the funds is subject to a CSV delay (typically 144-1008 blocks). During this window, the counterparty can publish a revocation if the closing party cheated by broadcasting an old state.
• Vault constructions. Withdrawals can be forced through a multi-step delay, during which an alarm script can redirect funds if the withdrawal wasn't authorized.
• Eltoo (proposed). Would use CSV for its simplified state-replacement model.
• HTLC timeouts. Some HTLC variants use CSV-based timeouts that anchor to the HTLC's broadcast rather than to a wall-clock time.

CSV is paired with CLTV the way relative time is paired with absolute time. Together they make Bitcoin's layer-2 ecosystem possible. See BIP-68 for the underlying nSequence semantics and CLTV for the absolute-time counterpart.