OP_CHECKTEMPLATEVERIFY

Anna wants to set aside funds to be divided later between Peter and Eva. She does not want to rely only on a promise from someone holding the money. In Bitcoin, unspent funds are recorded as transaction outputs, called UTXOs; each carries an amount and the conditions for using it. CTV could add a particular distribution plan to those conditions. When someone spends the output, nodes—the programs checking the network’s rules—would verify that the new transaction follows the plan. A different recipient or prescribed amount would fail the check. Jeremy Rubin describes this proposal in BIP119, which was assigned its BIP number in 2020. [1] [3]

The template specifies the transfer’s structure: how many earlier outputs the inputs refer to and which new outputs must be created. For the new outputs, it fixes both amounts and scripts, meaning their future spending conditions. In more detail, BIP119 also includes the transaction version; nLockTime, a field for transaction-wide time constraints; the input fields nSequence, which can affect timelocks; and the index of the input currently being checked. If any scriptSig, an input script providing spending data, is nonempty, a hash covering all scriptSig fields is included too. This is more than a recipient list: changing another covered field would also produce a different template. References to the particular older coins and their amounts are a separate question, explained below. [1]

A byte is a standard unit of data size. The proposed check uses a 32-byte template hash calculated with SHA256. The node calculates the same fingerprint from the transaction spending the output and rejects a mismatch. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. Another part of the script may require a signature; CTV does not universally replace it. Other argument lengths do not perform this check and are reserved for future extensions, though relay policy may reject them. An incorrect argument therefore does not automatically mean coins are safely locked. [1] [4] [12]

The following example uses sats, the smallest bitcoin units. The template hash does not directly include outpoints, meaning references to the specific UTXOs being spent, or their input amounts. The number of inputs is nevertheless fixed. Suppose exactly one input is allowed and outputs total 99,000 sats. An input worth 100,000 sats leaves 1,000 sats as a fee. An input below the output total cannot fund that transaction. With unchanged outputs, a larger input instead raises the fee; it does not automatically create change. [6] [9]

A template can require a transition to another output whose script contains a delay and a recovery path. This allows a vault to be assembled with time to react to an unwanted withdrawal. CTV is not the entire security system: keys, subsequent output conditions, monitoring and timely recovery confirmation all matter. Some restrictions can instead use presigned transactions, with different cooperation and key-deletion requirements. [8] [5]

A block groups transactions into a batch added to the shared history. In proposed congestion control, an initial output commits funds to a later distribution. Individual recipients’ outputs can be created in follow-up transactions, perhaps when the network is less busy. Recipients need information about the plan and a way to exercise their entitlement. This differs from an ordinary payment already confirmed to their address and does not turn a bounded block into unlimited space. [7] [11]

A wallet is an application or device for receiving and sending bitcoin. Anna might prepare the plan long before she needs to publish the payment, without knowing future fee rates. Fixed outputs prevent her from freely reducing the amount returned to her wallet and offering the difference to a miner. The construction therefore needs a way to add fees. One option is suitably prepared CPFP: a follow-up transaction spends an output of the original transaction and offers a fee intended to encourage a miner to include both. Another option is a template designed from the outset for an additional input. That input cannot simply be added to a template allowing only one. A mempool is an individual node’s collection of unconfirmed transactions; admission does not guarantee inclusion in a block. [2] [6] [10]

CTV alone checks a particular template; it is not a general language for reading and freely comparing all transaction data. It can support branching plans of future transactions, but its capabilities must not be confused with general recursive Covenants. Combinations with other proposed instructions may do more. Check whether a demonstration uses only CTV or a whole package of changes. [1] [2]

At the review on 17 October 2026, BIP119 has Draft status, meaning a proposal still in development. It would give OP_NOP4, an instruction that currently has no effect during block validation, a new checking function. This tightening of shared rules is called a Soft Fork. The document itself does not specify activation. Publishing a BIP does not make the opcode an enforced instruction; code, a developer’s support or a demonstration wallet does not establish enforcement on Bitcoin’s main network, mainnet. For any demonstration, identify the network, rules and other proposals it depends on. [1]

Until the rule is enforced, merely putting it in a script does not provide its intended protection; consensus and mempool rejection are different. Even with CTV support, a single mandatory template without an escape path can trap an underfunded output. A new small deposit does not automatically block other correctly funded UTXOs. Safe design needs checks of amounts, fees, backups and every recovery path. [1] [4] [6]