OP_CHECKTEMPLATEVERIFY (CTV)

OP_CHECKTEMPLATEVERIFY, abbreviated CTV and specified in BIP-119, is a proposed Bitcoin opcode that lets an output commit, in advance, to the exact transaction that may spend it. The opcode hashes a defined set of fields from the spending transaction — version, locktime, input count, sequence numbers, output count, the outputs themselves, and the spending input's position — and requires that hash to match a 32-byte value baked into the output's script. If the next transaction matches the committed template, the spend is valid; if it deviates in any committed field, consensus rejects it. Coins locked with CTV know their own future.

A deliberately limited covenant

CTV is a narrow form of covenant — the general class of mechanisms that let coins restrict how they may be spent next. Two design choices keep it small. First, the template hash notably does not commit to the input amounts or to the specific coins being spent, only to the shape and destinations of the spending transaction. Second, it is non-recursive in any open-ended sense: an output can dictate the one transaction that spends it, and that transaction's outputs can themselves be CTV outputs, but every step must be fully enumerated in advance — a finite, pre-computed tree, not a self-perpetuating rule that could trap coins in an infinite regress. This narrowness is the point: it aims to deliver useful functionality while minimizing the surface for unintended consequences, which is the standard by which conservative Bitcoin upgrades are judged.

What it would enable

The flagship applications are practical. Vaults: cold savings could be locked so the only permitted spend moves coins into a staged withdrawal with a built-in delay and a recovery path — a thief who steals your keys still cannot redirect funds past the template, a meaningful upgrade for self-custody. Congestion control: an exchange or pool could commit hundreds of payouts in a single small transaction during a fee spike, then fan them out later when block space is cheap — the recipients' claims are consensus-guaranteed from the first confirmation, an idea with obvious appeal to anyone watching the mempool during fee storms. Beyond those, CTV supports non-interactive Lightning channel openings, payment pools shared by many users in one UTXO, and more efficient discreet log contracts.

Status: proposed, not consensus

For miners specifically, covenants like CTV are worth watching because they reshape fee markets rather than mining itself. Congestion-control batching smooths fee spikes but sustains base demand for block space; vault adoption would add new transaction types with time-insensitive fee profiles, deepening the pool of patient demand that fills blocks between frenzies. As block subsidies decline with each halving, anything that broadens durable fee-paying use of the chain feeds directly into the long-term security budget every miner depends on. A healthier, more diverse fee market is not a side effect of covenant proposals — for the machines securing the chain, it is arguably the main event.

CTV is one of several covenant proposals under active community discussion, alongside approaches like AnyPrevOut. As of this writing it has not been activated on Bitcoin, and no activation timeline exists. Adding it would require a soft fork, and the debate is less about the code — the implementation is small — than about process: how Bitcoin should measure consensus for any change, and whether covenants as a category invite uses that alter Bitcoin's character. That conservatism is a feature. The entire value of the base layer rests on rules that do not change casually, and a proposal spending years under adversarial review is the system working as designed. CTV builds on the broader opcode machinery within Bitcoin Script; understanding those foundations makes the covenant debate legible.