Glossary / Protocol & upgrades
OP_CHECKTEMPLATEVERIFY
Also known as CTV, BIP119.
- Definition
- OP_CHECKTEMPLATEVERIFY is a proposed opcode that would let an output commit in advance to the exact transaction allowed to spend it, down to its outputs and amounts.
Specified in BIP-119.
BIP-119 describes it, Jeremy Rubin published the first draft in January 2020, and the network has not adopted it. The opcode would take a 32-byte hash from the stack and fail unless a hash of the spending transaction's template, meaning its version, locktime, input count, sequences, outputs and input index, matches. Nothing in your wallet uses it, and nothing will until a soft fork activates.
How it works
Status: proposed, not activated. BIP-119 has been a draft since 2020, a proposed activation in 2022 drew enough objection to be shelved, and Bitcoin Core contains no deployment parameters for it.
The design reuses an old upgrade trick. Opcode 179, previously OP_NOP4, currently does nothing at all, so a script containing it is valid to every node on the network. A soft fork would redefine that byte so upgraded nodes perform the check while old ones keep waving the script through, the same path CLTV took through OP_NOP2 and CSV through OP_NOP3.
What gets hashed is chosen with unusual care. The template covers the outputs, the amounts, the number of inputs and their sequence numbers, but deliberately leaves out the outpoints, meaning the txids of the coins being spent. Leaving them out has two consequences that the whole proposal rests on. First, you can compute the hash before the funding transaction exists, which is what lets you build a chain of future spends and then fund it. Second, a template cannot contain a commitment to itself, so the restriction cannot be made to repeat forever, which is why supporters call it the narrow covenant.
The result is a spend whose txid is known before it happens. A wallet can hand you a receipt for a payment that will exist later and prove that no other spend of that coin is possible.
Where you see it
OP_CHECKTEMPLATEVERIFY runs nowhere on mainnet, so the place to look is the set of applications built on custom signets that would ship if the opcode activated.
Congestion control is the most cited. An exchange facing a fee spike pays 1,000 withdrawals into a single output that commits to a tree of onward payments; each user can later expand their own branch and take delivery when fees fall, and the exchange has spent one output instead of a thousand. Vaults are the second: a withdrawal must first land in a staging output with a delay, giving you a window to claw the funds back to cold storage if the request was not yours. Payment pools and non-interactive Lightning channel funding use the same commit-then-expand shape.
For anyone buying bitcoin, the honest position is that this changes nothing you can act on. It is worth recognising the acronym because it turns up constantly in arguments about what bitcoin should become, and because the vault features some custody services advertise would be genuinely enforceable if it ever activated.
OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY
OP_CHECKTEMPLATEVERIFY constrains the shape of the spending transaction, while OP_CHECKLOCKTIMEVERIFY constrains when a spend may happen and says nothing about where the money goes. The near-identical names get the two confused constantly.
The other difference is status, and it is the one that matters. OP_CHECKLOCKTIMEVERIFY has been enforced since block 388,381 on December 14, 2015, and is used every day by Lightning, escrow scripts and inheritance wallets. OP_CHECKTEMPLATEVERIFY has never been enforced by a single node on mainnet. If a service tells you your coins are protected by a template commitment, it is describing something the network does not currently check.