This is Part 2 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article click here.
OP_CHECKTEMPLATEVERIFY (OP_CTV) was introduced by Jeremy Rubin in BIP 119. It sets spending rules using a straightforward template format that can specify the outputs, version, and locktime of the following transaction. The opcode accepts a commitment hash as input and mandates that any transaction running the opcode contains only outputs aligned with this commitment.
When executed, OP_CTV requires this 32-byte commitment hash to be on top of the stack. The opcode then generates a new StandardTemplateHash from the current spending transaction to compare against this commitment hash. The serialized components included in the StandardTemplateHash cover the transaction version and locktime, the number of inputs and outputs, and a hash of all outputs, which binds both their amounts and their locking scripts (scriptPubKeys). If the transaction fits the template, OP_CTV places a 1 on the stack to indicate success; otherwise, it places a 0 to indicate failure.
A simple locking script using OP_CTV would look like
To demonstrate a more sophisticated use of OP_CTV, imagine Alice wants to build a vault—a Bitcoin UTXO spending policy that limits how funds can be moved by routing them through predefined withdrawal paths. To access her funds, they must first be transferred to an intermediary address, from which they can either reach her hot wallet after a 100-block delay, or be instantly returned to secure cold storage if a security breach occurs. This setup requires three transaction templates and two OP_CTV ScriptPubKeys.
To fund this vault, she creates a vault output restricted by OP_CTV that commits to just one transaction template, Tx_Unvault. This template moves the vault UTXO to a second OP_CTV address, producing the intermediate unvaulting output. The intermediate output, in turn, supports two spending templates. The first template, Tx_Hot, represents the standard withdrawal path and moves the unvaulting output to her hot wallet after a 100-block relative timelock enforced by OP_CHECKSEQUENCEVERIFY (OP_CSV) via the previous transaction’s nSequence. The second template, Tx_Cold, represents the emergency recovery path that can be activated if her keys are compromised. It redirects the attempted unvault straight back to cold storage without any delay.
Alice calculates a CTV commitment hash for each template. She then builds the vault’s locking script as a P2WSH output, committing to the redeem script displayed in Figure 1.
Figure 1: Hot Branch Spend of Alice’s P2WSH Transaction
OP_0
OP_IF
<100> OP_CHECKSEQUENCEVERIFY
OP_DROP
OP_ELSE
OP_ENDIF
)>
Source: Cointelegraph Research
If Alice follows the standard withdrawal path, she waits 100 blocks, constructs Tx_Hot exactly as precommitted, and supplies her hot key signature with OP_1 to select the first branch. The relative timelock countdown only starts once an attempt is made to unvault the funds. In either scenario, the spending transaction must precisely match one of the pre-committed templates.
The constraints achievable with OP_CTV are comparable to those already possible through pre-signed transactions. However, OP_CTV eliminates the need to create and later discard temporary keys. Since OP_CTV does not commit to txids, an OP_CTV address can be reused, provided it is funded with the exact amount required by the output template. If the UTXO sent to an OP_CTV address is too small, it may become unspendable. If it is too large, the surplus may become a mandatory miner fee. OP_CTV offers a more trust-minimized approach for building vaults, congestion-control mechanisms, and other smart contract building blocks, though some of the inflexibility of pre-signed transactions still applies.
In our next article we will begin exploring SIGHASH_ANYPREVOUT (APO), another widely discussed opcode proposal that fully enables covenant functionality.
