CTV (CheckTemplateVerify)

What Is CheckTemplateVerify?

CheckTemplateVerify (CTV) is a proposed Bitcoin opcode specified in BIP 119, authored by Jeremy Rubin. It introduces a minimal form of covenant to Bitcoin: a spending condition that restricts not just who can spend coins, but how they can be spent. With CTV, a UTXO can be locked so that the only valid spending transaction must match a predetermined template covering outputs, amounts, and structure.

Originally proposed in 2019 under the name OP_CHECKOUTPUTSHASHVERIFY (COSHV) and later renamed OP_SECURETHEBAG, the opcode was refined into its current form and formally specified as BIP 119 in January 2020. It would be deployed as a soft fork by repurposing the existing OP_NOP4 opcode (0xb3), meaning older nodes would still accept CTV transactions as valid.

CTV is deliberately narrow in scope. Unlike more expressive proposals such as OP_CAT, CTV cannot create arbitrary smart contracts or recursive covenants. It can only verify that a spending transaction matches a single, fully-specified template. This minimalism is both its primary strength (safety and simplicity) and its main criticism (limited flexibility).

How It Works

When a Bitcoin Script containing OP_CHECKTEMPLATEVERIFY executes, the opcode pops a 32-byte hash from the stack and compares it against a hash computed from the spending transaction's fields. If the hashes match, execution continues. If they differ, the transaction is invalid.

The Template Hash

The template hash commits to the following transaction fields, concatenated in this specific order and then hashed with SHA-256:

1. nVersion (4 bytes): the transaction version number
2. nLockTime (4 bytes): the transaction locktime
3. scriptSigs hash (32 bytes, conditional): SHA-256 of all input scriptSigs, included only if any input has a non-empty scriptSig (omitted for SegWit-only transactions)
4. Number of inputs (4 bytes): count of transaction inputs
5. Sequences hash (32 bytes): SHA-256 of all input nSequence values
6. Number of outputs (4 bytes): count of transaction outputs
7. Outputs hash (32 bytes): SHA-256 of all serialized outputs (amounts and scriptPubKeys)
8. Input index (4 bytes): index of the input currently being evaluated

What Is Excluded

Certain fields are intentionally left out of the template hash, and each exclusion serves a specific design purpose:

• Input prevouts (txids and vouts): excluded so the same template can be reused across different UTXOs, enabling predictable child transaction IDs
• Input amounts: excluded because committing to outputs already constrains spending (input amounts minus output amounts equals the fee)
• scriptPubKey of the current input: excluded because including it would create a hash cycle where the script would need to commit to itself

Script Construction

A CTV-locked output uses a simple script that pushes the expected template hash onto the stack and then calls the opcode:

# CTV script structure
<32-byte template hash> OP_CHECKTEMPLATEVERIFY

# Example in a Taproot script path
OP_PUSH32 0xabcdef...1234 OP_CHECKTEMPLATEVERIFY

The spending transaction must exactly match the committed template. There is no partial matching or flexibility: the outputs, their amounts, and the transaction structure must all correspond to the pre-committed hash.

Reference Implementation

The hash computation follows a specific algorithm. The BIP provides pseudocode for the DefaultCheckTemplateVerifyHash function:

def get_default_check_template_hash(tx, nIn):
    r = b""
    r += struct.pack("<i", tx.nVersion)
    r += struct.pack("<I", tx.nLockTime)
    if any_non_null_scriptSig(tx):
        r += sha256(serialize_scriptSigs(tx))
    r += struct.pack("<I", len(tx.vin))
    r += sha256(serialize_sequences(tx))
    r += struct.pack("<I", len(tx.vout))
    r += sha256(serialize_outputs(tx))
    r += struct.pack("<I", nIn)
    return sha256(r)

The specification requires implementations to cache the intermediate hashes (scriptSigs hash, sequences hash, outputs hash) to prevent quadratic hashing attacks, where a maliciously constructed transaction could force repeated computation across multiple inputs.

Use Cases

Vaults

CTV enables security vaults where funds can only be spent to a predetermined intermediate address with a time delay. If a user's keys are compromised, the attacker cannot immediately steal funds. Instead, the spending transaction must follow the vault template, giving the owner a window to detect the unauthorized spend and sweep funds to a recovery address.

The vault pattern works in two stages. First, the attacker triggers the CTV-locked withdrawal, which sends funds to a time-delayed intermediate script. Second, during the delay period (enforced via CSV), the legitimate owner detects the unauthorized transaction and uses a pre-signed recovery path to redirect funds to a secure cold storage address.

Congestion Control

During periods of high mempool congestion, a payment processor handling hundreds of payouts can use CTV to commit all recipients to a single on-chain transaction. The CTV output encodes a tree of future transactions that will expand into individual payments when block space becomes cheaper.

This reduces an O(n) on-chain footprint to O(1) during peak fee periods. Recipients can trust that their payout is guaranteed by the CTV commitment, even before the expansion transactions confirm. Each recipient can independently force their branch of the tree on-chain whenever they choose, without cooperation from the payment processor.

Payment Pools

Multiple users can pool funds into a single UTXO with CTV-enforced individual withdrawal rights. Each participant has a guaranteed unilateral exit path embedded in the covenant template. This improves on-chain efficiency (one UTXO instead of many) and privacy (shared UTXO obscures individual holdings) while maintaining self-custody guarantees.

Channel Factories

Channel factories allow multiple Lightning channels to be created from a single on-chain transaction. Without CTV, all factory participants must pre-sign unilateral exit transactions, requiring interactive multi-round communication. CTV eliminates this requirement by embedding the exit conditions directly in the covenant, reducing setup from two communication rounds to one.

Non-Interactive Payment Channels

CTV enables creating payment channels where the counterparty does not need to be online during setup. The spending conditions are embedded in the template rather than requiring interactive signatures. This is particularly useful for services that want to pre-fund channels for users who have not yet come online.

CTV Compared to Other Covenant Proposals

Several covenant proposals compete for inclusion in Bitcoin. Each represents a different tradeoff between expressiveness and risk. For a deeper analysis of the covenant debate, see the OP_CAT covenant debate research article and the covenants explained deep dive.

CTV is the most conservative option. It cannot create recursive covenants because it does not commit to input prevouts: constructing a scriptPubKey containing a CTV hash that references itself would require solving a hash cycle (approximately 2^128 operations), which is computationally infeasible. OP_VAULT (BIP 345) actually depends on CTV internally, adding vault-specific recovery logic on top. Meanwhile, OP_CAT enables far broader programmability but also introduces risks around recursive covenants and potential MEV extraction on Bitcoin.

Current Status

As of 2026, CTV remains a draft BIP and has not been activated on Bitcoin mainnet. The proposal has been under discussion since 2019 and has undergone extensive review, but it has not achieved the broad consensus that previous soft forks like Taproot reached before activation.

In April 2022, Jeremy Rubin proposed activating CTV via Speedy Trial and released an activation client. The attempt was met with significant opposition from developers and community members who felt sufficient consensus had not been reached. Rubin called off the activation attempt within weeks, acknowledging the lack of agreement.

In February 2026, a new CTV activation client was published with concrete BIP 9 deployment parameters: a 90% miner signaling threshold (1,815 of 2,016 blocks), a signaling start of March 30, 2026, and a timeout of March 30, 2027. Whether CTV will achieve the required miner signaling remains uncertain, and the broader Bitcoin community has not reached consensus on activation methodology for covenant proposals.

Why It Matters

CTV represents one of the most significant potential upgrades to Bitcoin Script since Taproot. By enabling even basic covenants, CTV would unlock new categories of Bitcoin applications that are currently impossible: trustless vaults for institutional custody, efficient batching for exchanges handling high transaction volumes, and payment pools that improve both scalability and privacy.

For Layer 2 protocols like Spark and the Lightning Network, covenants could significantly improve channel construction, reduce the number of on-chain transactions required for setup, and enable new protocol designs that do not require all participants to be online simultaneously.

Risks and Considerations

Activation Uncertainty

CTV has not achieved community consensus despite years of review. The 2022 activation controversy highlighted the difficulty of reaching agreement on Bitcoin protocol changes. Developers remain divided on whether CTV alone provides sufficient value, or whether a more expressive covenant opcode should be adopted instead.

Scope Limitations

CTV's minimalism is a double-edged sword. Its narrow design prevents misuse but also limits its utility. Critics argue that adopting CTV will immediately create demand for additional covenant opcodes, leading to pressure for further soft forks. Proponents counter that CTV's conservative scope is precisely what makes it safe enough to deploy first.

Fungibility Concerns

Covenants broadly raise questions about Bitcoin's fungibility. If coins can be permanently restricted in how they are spent, some coins could be perceived as less valuable than unrestricted ones. CTV mitigates this concern because its covenants are finite: they expand through a predetermined tree and terminate, never creating permanent restrictions.

P2SH Incompatibility

CTV is incompatible with P2SH (Pay-to-Script-Hash) transactions. The template hash must commit to the scriptSig, which for P2SH would contain the redeemScript. Since the redeemScript itself contains the template hash, this creates an unsolvable hash cycle. CTV is designed to work with SegWit and Taproot outputs.

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.