OP_CHECKSEQUENCEVERIFY

The opcode reads a number from the stack and compares it against the sequence field of the input being spent, so the clock starts when the coin lands in a block rather than on a calendar date. BIP-112 defined it and the network began enforcing it at block 419,328 on July 4, 2016. Every Lightning channel you open depends on it.

How it works

Opcode 178 used to be OP_NOP3 and did nothing, which is how the rule reached the network as a soft fork rather than a split.

The check runs against three inputs: the number on the stack, the sequence field of the input being spent, and the transaction's version. Version 2 or higher is required, because the relative timelock rules of BIP-68 only apply from that version onward. If the top bit of either value is set, the timelock is switched off and the opcode gives up. Otherwise the two must agree on their unit and the stack value must not exceed the sequence field.

Units come in two flavours and they cannot be mixed in one comparison. Clear a particular flag and the number counts blocks; set it and the number counts intervals of 512 seconds. Sixteen bits are available either way, so the ceiling is 65,535 blocks, roughly 455 days, or the same count of 512-second intervals, which lands a little under 389 days. Anything longer needs an absolute timelock instead.

Failure is not a delay, it is a rejection. Before the waiting period is up the spend is not a pending transaction sitting in a queue, it is an invalid one that no node will relay and no miner will include. Nothing needs to be retried until the coin is old enough, at which point the identical transaction becomes valid.

Where you see it

Lightning is the largest user by volume, and the opcode is in the script protecting your own side of every channel.

When a channel closes unilaterally, the closing party's balance goes into an output that cannot be swept until a delay has passed, the to_self_delay of BOLT 3, commonly a few hundred blocks. The delay exists so that the other peer has a window to publish a revocation and take the funds if the close used an outdated state. Your money is safe either way, but this is why a force close leaves you waiting a day or more while a cooperative close pays out immediately.

The same construction shows up in submarine swaps and atomic swaps, where a refund path must open only after the counterparty has had a fair chance to claim, and in recovery wallets where a backup key becomes usable after a long silence.

One trap deserves a warning. A relative timelock measures from the confirmation of the specific coin being spent, so it restarts every time that coin moves. Consolidating dust, sweeping change, or letting a wallet reshuffle your outputs will reset the countdown on every recovery branch you have set up, and a heir who expected the backup key to work next month may find the clock back at zero.

OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY

CSV asks how long the coin has existed; CLTV asks what time it is. The two opcodes sit next to each other in the numbering, 178 and 177, and they are chosen for very different jobs.

Use the absolute form when the deadline is a real date: a trust that unlocks in 2030, a refund that expires at a known height. Use the relative form when the wait should begin whenever the contract starts, which is what any script written once and reused many times needs. Lightning could not use absolute timelocks for channel delays, because a channel opened today and a channel opened next year would need different scripts. The pair also arrived a few months apart, CLTV at block 388,381 on December 14, 2015 and CSV the following July, and the second existed largely because the first was not enough to build payment channels.