Overview
OP_CHECKTEMPLATEVERIFY (CTV), proposed in BIP119 by Jeremy Rubin, is a Bitcoin opcode that would enable a form of covenant, a restriction on how a Bitcoin output can be spent in the future. Specifically, CTV allows an output to commit to a template of the transaction that will spend it, constraining the number of outputs, their amounts, their destinations, and other transaction fields. If the spending transaction does not match the committed template, the script fails and the spend is invalid.
Covenants represent a significant conceptual shift in Bitcoin's scripting model. Today, Bitcoin Script can only verify that the spender has authorization (through signatures, hash preimages, timelocks, etc.), but it cannot restrict what the spender does with the funds once authorized. CTV would add the ability to say, in effect: "This bitcoin can be spent, but only into these specific outputs." This opens up a range of new applications that are currently impossible or impractical.
How It Works
Current Bitcoin Script:
────────────────────────────────────────────────────
Output: "Anyone with key K can spend this"
Spending tx can send funds ANYWHERE
Script only checks: does the spender have key K?
CTV-Enabled Script:
────────────────────────────────────────────────────
Output: "Anyone with key K can spend this,
BUT the spending transaction MUST match
this exact template hash"
Spending tx MUST have:
✓ Specific number of outputs
✓ Specific output amounts
✓ Specific output scriptPubKeys
✓ Specific nVersion, nLockTime, nSequence
If template doesn't match → spend FAILS
CTV works by hashing a "default template" that includes the spending transaction's version, locktime, number of inputs, sequences, number of outputs, outputs hash, and input index. The opcode takes this hash from the stack and compares it against the hash of the actual spending transaction. This is a simple, narrowly-scoped check that adds minimal complexity to the script interpreter.
Template Hash Covers:
┌──────────────────────────────────┐
│ nVersion │
│ nLockTime │
│ scriptSigs hash (if non-empty) │
│ Number of inputs │
│ nSequence of each input │
│ Number of outputs │
│ Hash of all outputs │
│ Index of the current input │
└──────────────────────────────────┘
Use Cases
Vaults
CTV enables a more practical form of Bitcoin vaults. An output locked with CTV can be constrained so that it can only be spent into a time-locked intermediate address, creating an enforced waiting period during which the owner can detect and respond to unauthorized spending attempts. Unlike pre-signed transaction vaults, CTV vaults do not require storing pre-signed transactions and cannot be compromised by losing those transactions.
Congestion Control
During periods of high on-chain demand, a service like an exchange could batch withdrawals into a single CTV-committed transaction tree. One on-chain transaction commits to the entire tree of future payouts, and individual recipients can claim their funds later when fees are lower. This effectively allows payment commitments to be made on-chain without immediately consuming block space for every individual payment.
Payment Pools
CTV can be used to construct payment pools where multiple users share a single UTXO but each can unilaterally exit with their funds through a pre-committed transaction tree. This is a building block for scaling solutions that reduce the on-chain footprint of multi-party arrangements.
Non-Interactive Lightning Channels
CTV could simplify Lightning Network channel opens by allowing non-interactive channel setups. A sender could create a channel with a recipient without requiring the recipient to be online during the funding transaction, reducing the coordination overhead of Lightning.
Controversy and Debate
CTV has been one of the most actively debated Bitcoin upgrade proposals. Supporters argue that it is a minimal, well-understood change that enables important functionality with very little added complexity. The opcode is deliberately narrow in scope: it constrains spending to a specific template but does not enable recursive covenants or arbitrary programmability.
Critics have raised several concerns. Some worry that any covenant mechanism, even a limited one, could be used to create "tainted" coins that are restricted in how they can be spent, potentially undermining Bitcoin's fungibility. Others argue that the Bitcoin community should evaluate the full design space of covenant proposals (including OP_VAULT, SIGHASH_ANYPREVOUT, and others) before committing to any single approach. The activation method has also been contentious, with disagreements about whether CTV has achieved sufficient consensus for deployment.
Related Concepts
- Opcode — The instruction category that CTV belongs to
- Bitcoin Script — The scripting language that CTV extends
- Vault — A primary use case enabled by CTV covenants
- Spending Condition — The broader category of rules CTV can enforce
- Taproot — The upgrade that provides an efficient execution context for CTV via Tapscript