OP_CHECKSEQUENCEVERIFY (OP_CSV)

What Is OP_CHECKSEQUENCEVERIFY?

OP_CHECKSEQUENCEVERIFY (commonly abbreviated OP_CSV) is a Bitcoin Script opcode that enforces a relative timelock on a transaction output. Unlike an absolute timelock that locks funds until a specific block height or date, a relative timelock locks funds for a duration measured from the moment the output is confirmed in a block. This makes OP_CSV ideal for protocols where the confirmation time is not known in advance, such as Lightning channels.

OP_CSV was introduced in BIP 112, authored by BtcDrak, Mark Friedenbach, and Eric Lombrozo. It activated at block #419,328 on July 4, 2016, as part of a soft fork that also included BIP 68 (consensus-enforced sequence numbers) and BIP 113 (median time-past for lock-time evaluation). The opcode redefines the previously unused OP_NOP3, assigned opcode value 0xb2.

Before OP_CSV, Bitcoin had only absolute timelocks via OP_CHECKLOCKTIMEVERIFY (BIP 65). Payment channel designs using absolute timelocks required a fixed expiration date set at channel opening, forcing channels to close before the deadline or risk fund theft. OP_CSV eliminated this limitation by enabling lock durations relative to confirmation, which is why it became a prerequisite for practical Lightning Network deployment.

How It Works

OP_CSV operates by comparing a value on the script stack against the spending transaction input's nSequence field. If the relative lock-time encoded in the nSequence field has not been satisfied, the script evaluation fails and the transaction is invalid. If the condition is met, execution continues as if a NOP was executed (the stack is unchanged).

The mechanism relies on two companion BIPs working together:

• BIP 68 gives consensus-enforced meaning to the nSequence field of transaction inputs, ensuring miners will not include a transaction in a block unless the relative lock-time has elapsed since the referenced output was confirmed
• BIP 112 (OP_CSV) makes that nSequence field accessible from within Bitcoin Script, allowing script authors to require a specific relative lock-time as a spending condition

The spending transaction must use version 2 or higher. If the transaction version is less than 2 and the disable flag is not set, the script fails.

The nSequence Field Encoding

BIP 68 repurposes the 32-bit nSequence field of each transaction input to encode relative lock-time values. The field is structured as follows:

Bit 31:     Disable flag (if set, no relative lock-time is enforced)
Bits 23-30: Reserved (must be zero)
Bit 22:     Type flag (0 = blocks, 1 = time-based)
Bits 16-21: Reserved (must be zero)
Bits 0-15:  Lock-time value (0 to 65,535)

Three constants define the field layout:

SEQUENCE_LOCKTIME_DISABLE_FLAG = 0x80000000  // bit 31
SEQUENCE_LOCKTIME_TYPE_FLAG   = 0x00400000  // bit 22
SEQUENCE_LOCKTIME_MASK        = 0x0000ffff  // bits 0-15

Block-Height Mode vs. Time-Based Mode

When bit 22 (the type flag) is unset, bits 0 through 15 encode a number of blocks. The output cannot be spent until that many blocks have been mined after its confirmation. With a range of 0 to 65,535 blocks, this allows relative locks of up to approximately 455 days at 10 minutes per block.

When bit 22 is set, bits 0 through 15 encode a number of 512-second intervals. The 512-second granularity was chosen because Bitcoin targets 600-second block intervals, and this resolution provides sufficient precision for protocol use cases while fitting within 16 bits. The maximum time-based lock is 65,535 × 512 seconds, or approximately 388 days.

When OP_CSV compares the stack value against the nSequence field, the type flags must match. A block-height lock cannot be compared against a time-based nSequence value, and vice versa. If the types differ, the script fails.

Script Example

A script requiring a 144-block relative delay (approximately one day) before the owner can spend:

// Require 144 blocks after confirmation
<144>
OP_CHECKSEQUENCEVERIFY
OP_DROP
<pubkey>
OP_CHECKSIG

The spending transaction must set the input's nSequence to at least 144 (with the disable flag unset and the type flag unset for block-height mode). If fewer than 144 blocks have elapsed since the output was confirmed, the transaction will be rejected by the network.

OP_CSV vs. OP_CHECKLOCKTIMEVERIFY

Bitcoin has two timelock opcodes, and understanding their differences is essential. For a comprehensive comparison, see the Bitcoin timelocks deep dive.

The practical distinction: OP_CLTV says "cannot spend before block 900,000" while OP_CSV says "cannot spend until 144 blocks after this output is confirmed." OP_CSV is more flexible for protocols because it does not require knowing when the output will be created.

Use Cases

Lightning Network Penalty Mechanism

OP_CSV is a critical building block of the Lightning Network's security model. Every commitment transaction uses OP_CSV to create a delay on the broadcaster's own funds. The to_local output in a commitment transaction uses a script with two spending paths:

OP_IF
    <revocationpubkey>
OP_ELSE
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

The first path allows the counterparty to spend immediately using a revocation key. The second path forces the broadcaster to wait to_self_delay blocks (enforced by OP_CSV) before claiming their own funds. This delay, typically 144 to 2,016 blocks (one day to two weeks), is negotiated when the channel opens.

If a party publishes a revoked (outdated) commitment transaction, the counterparty holds the revocation key for that state. Because the cheater's funds are locked behind the OP_CSV delay, the honest party has time to detect the breach and broadcast a justice transaction that sweeps the entire channel balance. This is the LN-Penalty enforcement mechanism.

Watchtower Protection

The CSV delay window also enables watchtowers: third-party services that monitor the blockchain on behalf of offline nodes. If a watchtower detects a revoked commitment transaction being broadcast, it can submit the penalty transaction during the OP_CSV delay period. Without the relative timelock, there would be no window for watchtowers to act. For more on how this works, see Lightning watchtowers explained.

Anchor Outputs and Anti-Pinning

The Lightning specification's anchor outputs feature adds a 1-block OP_CSV lock to all HTLC spending transactions. This prevents certain transaction pinning attacks where a malicious party could attach a low-fee child transaction to prevent the HTLC from being confirmed promptly. The 1-block CSV lock ensures that HTLC transactions cannot be immediately spent, giving the honest party time to use child-pays-for-parent fee bumping.

Bitcoin Vaults

Vault constructions use OP_CSV to create a withdrawal delay. When funds are moved out of a vault, they first go to an intermediate address locked with a relative timelock. During this waiting period, the vault owner can claw back the funds if the withdrawal was unauthorized. More advanced vault designs using covenants complement OP_CSV rather than replace it.

Escrow and Payment Protocols

OP_CSV enables time-locked escrow without trusted intermediaries. A multi-signature output can include an OP_CSV path that allows one party to reclaim funds after a timeout, ensuring that funds are never permanently locked if the other party becomes unresponsive. This pattern appears in payment channel designs and atomic swap protocols.

Why It Matters

OP_CSV transformed what is possible on Bitcoin by enabling protocols that rely on relative time guarantees. Before OP_CSV, payment channels had fixed expiration dates, limiting their practicality. After OP_CSV, channels could remain open indefinitely because the security mechanism activates only when a commitment transaction is broadcast, not at a predetermined deadline.

This relative timelock capability is what makes the Lightning Network's penalty mechanism work at scale. Layer 2 protocols like Spark build on these Bitcoin Script primitives to enable fast, low-cost transactions while preserving the security guarantees of the base layer. Understanding OP_CSV is essential for anyone working with Bitcoin Layer 2 technology or building applications that use Bitcoin Script programmability.

Risks and Considerations

Maximum Lock Duration

The 16-bit value field limits relative timelocks to 65,535 blocks (approximately 455 days) or 65,535 × 512 seconds (approximately 388 days). Protocols requiring longer lock periods cannot rely solely on OP_CSV and must use alternative mechanisms or combine it with absolute timelocks.

Transaction Version Requirement

OP_CSV requires the spending transaction to use version 2 or higher. While this is standard for modern Bitcoin software, legacy transaction-building tools that default to version 1 will produce invalid transactions when spending OP_CSV-locked outputs.

Type Flag Mismatch

If the type flag (bit 22) in the script value does not match the type flag in the spending input's nSequence field, the script fails. Developers must ensure consistency between the locking script and the spending transaction. Mixing block-height and time-based modes is a common implementation error.

Interaction with Replace-By-Fee

The nSequence field serves double duty: BIP 68 uses it for relative timelocks, while BIP 125 uses nSequence values below 0xfffffffe to signal replace-by-fee (RBF) opt-in. Since OP_CSV requires the disable flag (bit 31) to be unset, any OP_CSV-locked input automatically signals RBF eligibility. Protocol designers should account for this when reasoning about transaction replaceability.

Future Evolution

The proposed eltoo (LN-Symmetry) protocol would simplify Lightning's enforcement mechanism by allowing any later channel state to replace any earlier state, removing the need for the penalty-based revocation that OP_CSV currently enables. This requires a new sighash flag (SIGHASH_ANYPREVOUT, BIP 118) that has not yet been activated. If adopted, OP_CSV would still be used for timelocking but the overall channel design would change significantly.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.