OP_CHECKSEQUENCEVERIFY (CSV)

OP_CHECKSEQUENCEVERIFY, abbreviated CSV, is a Bitcoin Script opcode defined in BIP 112 that enforces a relative timelock. Rather than a fixed calendar deadline, CSV requires that a minimum amount of time has elapsed since the output being spent was confirmed. It redefined the previously unused OP_NOP3, activating as a soft fork in mid-2016 alongside BIP 68 (relative locktime semantics for nSequence) and BIP 113 (median-time-past evaluation) — a coordinated trio that gave Bitcoin contracts a reliable "wait N after confirmation" primitive without breaking older nodes.

How CSV reads nSequence

When CSV executes, it checks the value on the stack against the relative locktime encoded in the spending input's nSequence field, per BIP 68. Bit 22 (the type flag) selects the units: unset means the lock is measured in blocks with single-block granularity; set means it is measured in 512-second intervals. Bit 31 (the disable flag) turns relative-locktime enforcement off entirely — if it is set, CSV behaves as a NOP, preserving backward compatibility. The script fails unless the input being spent has aged at least as long as the script demands, counted from the block in which the output was confirmed. Because the clock starts at confirmation rather than at a wall-clock date, the same script template works identically whether the coins were locked yesterday or years ago.

Where it is used

CSV is the workhorse of the Lightning Network. Channel commitment transactions give the remote party's revocation path a CSV delay: if your counterparty broadcasts an outdated channel state, the delay forces their funds to sit frozen for a negotiated window (commonly on the order of hundreds to over a thousand blocks) during which you can present the revocation key and claim the cheater's balance. Without a relative timelock, that justice window could not exist. The same primitive underpins HTLC resolution paths, watchtower response windows, and any protocol where one party needs guaranteed time to react on-chain. Beyond Lightning, CSV appears in vault-style wallet constructions that impose a mandatory cooling-off period between initiating and completing a withdrawal — giving the rightful owner time to detect theft and sweep funds through a faster recovery path.

Relative versus absolute, and why both exist

CSV governs elapsed time since confirmation; its sibling OP_CHECKLOCKTIMEVERIFY (CLTV) governs absolute deadlines — a specific block height or timestamp, set via the transaction's nLockTime. Contracts routinely combine both: a Lightning HTLC uses CLTV for its absolute expiry and CSV for the local revocation delay. The time-based interpretation both opcodes rely on is anchored by Median Time Past (MTP), which prevents miners from gaming timestamps to unlock coins early. For anyone running their own node and channels, CSV is a quiet piece of sovereignty infrastructure: it is the mechanism that lets you enforce your side of a payment channel with nothing but script and patience — no court, no custodian, just consensus rules holding the clock. Since Taproot, these timelock branches can also hide inside key-path spends, invisible unless actually used.

Seeing CSV in the wild

You do not need to write script to encounter CSV; you need only close a Lightning channel. The "timelocked balance" your node reports after a force-close is a CSV delay executing exactly as designed — your own funds held to the same rules that would hold a cheater's, because the script cannot know in advance which party broadcasts. Wallet interfaces that show funds "maturing" over some number of blocks are rendering nSequence arithmetic into a progress bar. This is worth appreciating: relative timelocks are among the few contract tools that work identically for a two-channel hobbyist node and an industrial routing operation, with no permission, registration, or minimum size — consensus rules as the great equalizer.