OP_CSV Timelocks Explained: How Bitcoin Enables On-Chain Inheritance

Bitcoin does not have Ethereum-style smart contracts, but it has something powerful enough to enable programmable inheritance: Script opcodes. Specifically, OP_CSV (CheckSequenceVerify) allows Bitcoin transactions to be time-locked relative to when they were confirmed on-chain, creating the foundation for dead man's switch mechanisms on the Bitcoin blockchain.

This article explains how OP_CSV works, why it matters for Bitcoin inheritance, and how HeirVault uses it to create native BTC inheritance vaults.

What Is OP_CSV?

OP_CSV, formally known as OP_CHECKSEQUENCEVERIFY, is a Bitcoin Script opcode introduced in BIP 112 (activated in 2016). It enforces a relative timelock on a transaction output — meaning the output cannot be spent until a specified number of blocks or time units have passed since it was confirmed.

The key distinction from OP_CLTV (CheckLockTimeVerify) is that OP_CSV uses relative time rather than absolute time:

• OP_CLTV: "This output cannot be spent until block height 900,000" (absolute).
• OP_CSV: "This output cannot be spent until 4,320 blocks after it was confirmed" (relative — approximately 30 days).

Relative timelocks are ideal for inheritance because they can be reset. Every time the vault owner "checks in" by moving funds to a new output with a fresh OP_CSV lock, the inheritance countdown resets.

How OP_CSV Enables a Dead Man's Switch

The dead man's switch pattern on Bitcoin works by combining OP_CSV with multisig scripts:

The Script Structure

A simplified Bitcoin inheritance script has two spending paths:

Path 1 — Owner spends immediately. The owner can move funds at any time by providing their signature. No timelock applies.

Path 2 — Heirs spend after timelock. The designated heirs can spend the funds, but only after the OP_CSV timelock has expired. This requires both the timelock to elapse AND the heir signatures.

In Bitcoin Script pseudocode:

IF
  <owner_pubkey> CHECKSIG
ELSE
  <timelock_value> CHECKSEQUENCEVERIFY DROP
  <heir_threshold> <heir_pubkeys...> <n_heirs> CHECKMULTISIG
ENDIF

The Check-in Mechanism

The owner "checks in" by spending the current vault UTXO and creating a new one with the same script. This has two effects:

1. The funds move to a new output, resetting the OP_CSV countdown.
2. The old output is consumed and can no longer be claimed by heirs.

From the heirs' perspective, the clock starts over every time the owner transacts. Only when the owner stops transacting — and the full timelock period elapses — can heirs spend the output.

Sequence Numbers and BIP 68

OP_CSV works in conjunction with BIP 68, which redefines the nSequence field in transaction inputs. When a transaction input has its nSequence value set according to BIP 68 rules, it encodes the relative lock-time:

• Bit 22 clear: the value represents a block count (each unit = 1 block, approximately 10 minutes).
• Bit 22 set: the value represents time units (each unit = 512 seconds, approximately 8.5 minutes).

For inheritance purposes, block-based timelocks are generally preferred because they are deterministic — you know exactly how many blocks must pass, regardless of how quickly or slowly they are mined.

Practical Timelock Values

The maximum OP_CSV value is 65,535 blocks (approximately 455 days), which sets an upper bound on the timelock period for a single script.

P2SH and P2WSH: Wrapping the Script

Bitcoin inheritance scripts are typically deployed as Pay-to-Script-Hash (P2SH) or Pay-to-Witness-Script-Hash (P2WSH) addresses.

P2WSH (SegWit) is preferred because:

• Lower transaction fees (witness data is discounted)
• Better script validation
• Compatibility with modern wallets

The vault address looks like a standard Bitcoin address to external observers. The actual script conditions are only revealed when the funds are spent — providing a degree of privacy about the inheritance arrangement.

Multi-Heir Bitcoin Vaults

For estates with multiple heirs, the OP_CSV script is combined with OP_CHECKMULTISIG to require M-of-N heir signatures:

In a 2-of-3 configuration, three heir public keys are included in the script, and any two must sign to spend the timelocked output. This prevents any single heir from unilaterally claiming the inheritance.

The owner retains full control at all times — their spending path has no multisig requirement and no timelock. Only the heir path is subject to both constraints.

Grace Period Implementation

HeirVault's Bitcoin vaults implement a grace period by using a two-stage script:

1. Stage 1: After the initial timelock expires, the owner can still reclaim funds using their signature. This is the grace period window.
2. Stage 2: After a second timelock (the grace period) expires, heirs can claim with their multisig.

This two-stage approach mirrors the grace period mechanism in HeirVault's EVM smart contracts, providing the owner with a safety net against accidental switch triggers.

Comparing Bitcoin and EVM Inheritance

The key trade-off is flexibility vs. simplicity. Bitcoin scripts are limited but battle-tested and enforced by the most secure blockchain network. EVM contracts are more flexible but introduce additional smart contract risk.

Security Considerations

Script Immutability

Once a Bitcoin vault UTXO is created with an OP_CSV script, the script conditions cannot be changed. To update heir designations or timelock values, the owner must spend the current UTXO and create a new one with the updated script. This is by design — immutability prevents tampering.

Timelock Precision

Bitcoin's block time averages 10 minutes but varies. A 4,320-block timelock targets 30 days, but the actual elapsed time could be 28-32 days depending on mining difficulty adjustments. For inheritance purposes, this variance is negligible.

Fee Estimation

When heirs eventually claim the vault, the Bitcoin fee market may have changed significantly since the vault was created. Heirs should be prepared to pay the prevailing fee rate at claim time. HeirVault provides fee estimation guidance in the claim interface.

Getting Started with Bitcoin Inheritance

HeirVault's Bitcoin vault feature handles the OP_CSV script construction, UTXO management, and check-in process automatically. You connect a Bitcoin wallet (Unisat, Xverse, or Ledger), designate your heirs, choose a timelock period, and deposit BTC.

The technical complexity of Bitcoin Script is abstracted away — you interact with a clean interface while the underlying OP_CSV mechanisms enforce your inheritance rules on the Bitcoin blockchain.

Create your Bitcoin inheritance vault and ensure your BTC is protected for future generations.