Enforcing Delayed Spending in Bitcoin Multisig: A Vaulting Strategy with CHECKSEQUENCEVERIFY
Using native Bitcoin Script and Miniscript tools, we can design a secure 2-of-3 multisig with enforced spending delays.
Implementing Delayed Spending in 2-of-3 Bitcoin Multisig Using CHECKSEQUENCEVERIFY
Abstract
In the current landscape of Bitcoin self-custody, the need for secure, programmable spending restrictions has never been more apparent. While multisignature (multisig) schemes help reduce the risk of a single point of failure, they do not have built-in features to create delays that control when spending can happen. This paper explores the technical implementation of delayed spending for a 2-of-3 Bitcoin multisig policy using Bitcoin’s consensus-level opcode (CSV) and OP_CHECKSEQUENCEVERIFY presents an architecture for vaulting that enforces a spending delay—even after valid multisig approval—by utilizing Bitcoin Script and optional escape paths. This architecture is compatible with native SegWit and can be implemented using standard tooling, including Miniscript and Sparrow Wallet.
1. Introduction: Problem Statement
A 2-of-3 multisig configuration is a standard arrangement for collaborative custody, allowing any two signers to authorize a spend. However, traditional multisig lacks time-based control: once two valid signatures are collected, the transaction is immediately valid for broadcast. In the event of a compromise or malicious act on two keys, the funds transfer instantly, leaving no room for intervention.
To counteract this, we introduce a delay mechanism that enforces a mandatory waiting period — even after valid approval. This delayed spending behavior is referred to as a “vault,” allowing for advanced security models such as theft detection, spending alerts, and pre-signed emergency recovery transactions.
2. Bitcoin Script Foundations for Delayed Spending
Bitcoin offers two primary mechanisms for time-based restrictions at the consensus level:
OP_CHECKLOCKTIMEVERIFY (CLTV): Enforces an absolute block height or timestamp before a UTXO can be spent.
OP_CHECKSEQUENCEVERIFY (CSV): Enforces a relative delay in blocks or time after the UTXO is created.
In our architecture,OP_CHECKSEQUENCEVERIFYis the tool of choice, as it enables delayed spending after the UTXO has been confirmed—precisely what we require to defer execution of a multisig-approved transaction.
3. Vault Construction: Two-Stage Spend Model
To implement delayed spending in a 2-of-3 multisig setup, we design a two-phase vault:
3.1 Phase 1: Vault Funding
Two branches comprise a custom P2WSH script that locks in the funds:
Script Template (Pseudo-Script):
OP_IF
<N> OP_CHECKSEQUENCEVERIFY OP_DROP
2 <pubkey1> <pubkey2> <pubkey3> 3 OP_CHECKMULTISIG
OP_ELSE
<recovery_pubkey> OP_CHECKSIG
OP_ENDIFPrimary Path (IF branch): 2-of-3 multisig spend after a relative delay of
Nblocks.Secondary Path (ELSE branch): Emergency one-key recovery, optionally protected by OP_CHECKLOCKTIMEVERIFY a pre-signed transaction held offline.
3.2 Phase 2: Spend Transaction Construction
Once two cosigners agree to spend:
They sign a transaction, spending the UTXO via the primary CSV path.
The transaction must be set
nSequence >= Nfor each input to satisfy the relative lock condition.The transaction is held (e.g., in a watchtower queue or air-gapped signing device) until
Nblocks have elapsed since UTXO confirmation.Only then can it be broadcast and accepted by the network.
If malicious activity is detected during the delay period, the recovery key can optionally broadcast a competing transaction via the ELSE branch, moving funds to a secure location.
4. Technical Deep Dive: Implementing with Miniscript and Sparrow
4.1 Miniscript Policy
Miniscript offers a structured, type-safe representation of Bitcoin Scripts. Our policy can be expressed in Miniscript as:
or(
and_v(v:pk(recovery_key), older(N)),
and_v(v:older(N), thresh(2,pk(pubkey1),pk(pubkey2),pk(pubkey3)))
)This policy is:
Fully composable.
It is compatible with P2WSH.
This can be enforced via standard Bitcoin Core and PSBT tooling.
4.2 Creating the Vault in Sparrow Wallet
Launch Sparrow Wallet.
Go to
File → New Wallet → Create Wallet.Choose
Policy and select.Custom MiniscriptInsert the policy above.
Sparrow automatically derives the corresponding P2WSH address.
Fund the address with desired UTXOs.
When constructing spends:
Ensure
n Sequence >= N(e.g., 144 for a 1-day delay).Sparrow will verify script satisfaction based on the path selected.
You can export PSBTs for air-gapped signing or schedule the broadcast after the delay.
5. Security Considerations
5.1 Watchtower Integration
Implement a watchtower that monitors the blockchain for unauthorized spends from the vault address. The watchtower can preemptively broadcast a pre-signed recovery transaction if it detects a malicious transaction in the mempool or chain (if it is using the ELSE branch).
5.2 Timelock Granularity
CSV allows for delay units in blocks or time intervals (multiples of 512 seconds). A delay of one day is equivalent to 144 blocks, while a delay of one week is equivalent to 1,008 blocks. Use granularity appropriate to your threat model.
5.3 Attack Mitigations
If 2 of 3 keys are compromised, the attacker still must wait for
Nblocks.During this period, the recovery key or a third party can respond.
All logic is enforced by Bitcoin consensus, not policy or app-layer code.
Conclusion
By leveraging Bitcoin’s native OP_CHECKSEQUENCEVERIFY opcode in conjunction with a flexible 2-of-3 multisig structure, users can architect a sophisticated self-custodial vault that enforces a mandatory delay on any spending action—even after the required number of signers has approved the transaction. This delay is not a soft policy or third-party restriction but is enforced directly at the Bitcoin consensus layer, ensuring that no transaction can bypass the programmed waiting period.
This vaulting design introduces a powerful form of programmable friction — an intentional pause between authorization and execution — which significantly enhances the security posture of a multisig setup. It provides a critical window for detection, reaction, and mitigation in the event of key compromise or unauthorized activity. By adding a delay between signing and settlement, the system allows time for monitors, alerts, or offline protection methods to step in, making it much more difficult for attackers to quickly steal funds, even if they have worked together or compromised two keys.
Importantly, this model preserves full spending flexibility once the delay has matured. The signers are not locked into a predefined recipient or transaction, unlike traditional time-locked pre-signed models. Instead, they can construct and approve a transaction at the time of spending, providing a balance between security and usability.
Thanks to composable primitives like Miniscript and modern wallet interfaces such as Sparrow Wallet, deploying these vaulting mechanisms is no longer confined to protocol developers or scripting experts. Power users and security-conscious individuals can now implement this robust model using standard tools, without modifying Bitcoin Core or relying on external smart contract platforms.
As Bitcoin develops to become more independent and secure against attacks, this type of delay-enforced custody provides a key element for strong and future-ready cold storage solutions. It is a meaningful step toward practical censorship resistance, theft mitigation, and programmable monetary self-defense.
Appendix: CSV Encoding for nSequence
To trigger CSV, set nSequence to:
<N>= relative blocks (for block delay)Must not have the disable flag (
0x80000000)E.g.,
nSequence = 144→ ~1 day
Resources
Bitcoin Optech: OP_CHECKSEQUENCEVERIFY
Miniscript Policy Toolkit
You can sign up to receive emails each time I publish.
Link to the original Bitcoin White Paper: White Paper:
Dollar-Cost-Average Bitcoin ($10 Free Bitcoin): DCA-SWAN
Access to our high-net-worth Bitcoin investor technical services is available now: cccCloud
“This content is intended solely for informational use. It is not a substitute for professional financial or legal counsel. We cannot guarantee the accuracy of the information, so we recommend consulting with a qualified financial advisor before making any substantial financial commitments.