COVENANTS PART 1: CTV
With this article begins a series of deep dives aimed at exploring the main proposals for implementing covenants in Bitcoin: how they work, what implications they carry, and what the pros and cons of each may be. CheckTemplateVerify can only be the first protagonist.
To make everything clearer—and possibly understandable even to a non-technical audience—we must start from the basics.
- Bitcoin Script
Bitcoin Script is a simple, non-Turing-complete scripting language used to define spending conditions for Bitcoin transactions. An opcode (short for “operation code”) is essentially a command or function within a Bitcoin script. Opcodes operate on a set of data: for example, OP_ADD adds two numbers, while OP_EQUAL compares two values to check if they match. Opcodes can perform mathematical, logical, or cryptographic operations (such as OP_CHECKSIG, which verifies digital signatures), enabling the creation of basic smart contracts on Bitcoin.
Bitcoin Script also includes reserved opcodes—such as the various OP_NOP (no-operation)—which currently do nothing but are intended for potential future protocol upgrades. By leveraging one of these dormant opcodes, it becomes possible to introduce new functionalities through a soft fork: non-updated nodes will continue to treat the opcode as an instruction with no effect—still accepting it as valid—while updated nodes will interpret it according to its new meaning. This allows for a so-called backwards-compatible upgrade.
- The OP_CHECKTEMPLATEVERIFY opcode
OP_CHECKTEMPLATEVERIFY—abbreviated as OP_CTV—is an opcode proposed for Bitcoin via Bitcoin Improvement Proposal BIP-119 by Jeremy Rubin. The proposal involves reassigning the previously unused OP_NOP4 opcode, giving it a new semantics: that of OP_CHECKTEMPLATEVERIFY.
In simple terms, OP_CTV allows a script to constrain the output of a transaction so that it can only be spent through a specific predefined transaction (or from a predefined set of transactions). Technically, the locking script of a UTXO includes a 32-byte cryptographic hash—called a template hash or commitment hash—which represents the model of the authorized spending transaction. When someone attempts to spend that UTXO, OP_CTV verifies that the hash of the current transaction matches the one expected by the script.
In practice, OP_CTV locks the structure of a future on-chain transaction: version, locktime, number of inputs and outputs, hash of outputs (which includes destination addresses and amounts), and other fields are included in the hash checked by the opcode. This means that a UTXO protected by CTV can only be unlocked by a transaction that matches exactly the predefined template.
With CTV, the recipient can “pre-program” the future spending rules for the UTXOs they receive by generating an address containing specific spending conditions not visible to the sender. This creates what is generally known as a covenant. It's important to note that BIP-119 is deliberately designed to be non-recursive: the restriction applies only to the next transaction. In other words, OP_CTV enables predefined, one-step covenants rather than general or recursive ones that would continue to constrain the coins indefinitely. This limitation reduces complexity and potential risks, as we will explore later.
- Historical context: Jeremy Rubin and the Speedy Trial proposal
The proposal to introduce OP_CTV dates back to 2020, when developer Jeremy Rubin published BIP-119, complete with specifications and reference code.
Following the successful activation of the Taproot soft fork (November 2021), attention turned to what the next protocol upgrade could be. CTV was (and remains) one of the main candidates, alongside proposals like ANYPREVOUT (BIP-118) and the reintroduction of OP_CAT.
Rubin actively promoted CTV: during the 2022 Bitcoin Conference in Miami, he gathered feedback from developers and users, finding interest.
Shortly after, on April 19th, Rubin sent an email to the bitcoin-dev mailing list proposing a concrete plan to activate CTV through Speedy Trial. In brief, Speedy Trial is a fast-track method for activating a soft fork based on miner signaling: miners are given a short window to signal support for the upgrade in the blocks they produce, with a high threshold for activation (e.g., 90% of blocks within a difficulty period). If the threshold is reached within the allotted time, the upgrade is locked in for the next activation window; otherwise, it does not proceed. Taproot was activated in this manner.
Rubin hoped for a similar path, but the community's reaction was harsh. The reasons were varied, but the core concern was that a soft fork should never be activated lightly: only when there is near-unanimous consensus on the benefits of an upgrade should such a change to consensus rules be considered—ideally bundled with other enhancements under a single soft fork. Altering consensus is no small matter and must be approached with extreme caution, especially if it has been modified recently. Faced with growing criticism, Rubin eventually backed down.
- From Vaults to Channel Factories
Technically, CTV is appreciated by many for the new functionalities it could enable in Bitcoin. Here are the main ones:
* Covenants and constrained spending conditions: a basic example of a covenant might involve a two-phase payment: Alice sends BTC to Bob, but the script ensures that Bob can only spend those BTC by sending them to Carol. Without CTV, this would require pre-signed transactions or other workarounds. With CTV, the entire process can be encoded on-chain via the hash of the spending template.
* Vaults: one of the most discussed use cases is the construction of vaults—special addresses designed for long-term secure custody of bitcoin. In a CTV-based vault, the user can define in advance stringent conditions on how and when funds can be withdrawn. For example, cold storage funds could be restricted to move only to a pre-approved destination address (such as the user’s hot wallet) and with a limited amount per time interval. Vaults could significantly improve the security of self-custody by reducing theft risks.
* Congestion control: another promising application relates to on-chain scalability, specifically the efficient management of mempool congestion and transaction fees. The idea is to use CTV to batch and defer certain payments during periods of high network traffic, spreading them out when the network is less congested. Imagine a large exchange or payment processor needing to send 1,000 payments to customers. During a high-fee period, instead of broadcasting 1,000 separate transactions (competing for block space and driving up fees), it could issue a single on-chain transaction containing one aggregated output committed with CTV. This compact transaction would confirm immediately at low cost and act as a container: within it, the output is locked to a template that later expands into 1,000 individual transactions—executed when fees are lower. In essence, the business “reserves” space in an expensive block and fills in the payment details later, when cheaper. CTV separates the time of on-chain confirmation from the time recipients receive their outputs, optimizing total fee costs.
* Channel Factories: CTV opens up interesting possibilities for Lightning Network as well. A key concept is that of shared UTXOs, i.e., UTXOs jointly owned by multiple participants with predefined exit conditions, similar to what's described in the context of ARK. Many users could open Lightning channels together using a single on-chain transaction. For example, 50 channels could be opened with the on-chain cost of just one transaction.
Many of these schemes are theoretically possible today without CTV (using pre-signed transactions, time-lock sequences, complex multisig setups, etc.), but are impractical due to high coordination, interactivity, and trust requirements among participants. CTV automates and encodes these schemes at the consensus level, allowing them to be implemented in a trustless manner once the initial contract is distributed.
- Socio-political implications
Beyond its technical and economic potential, CTV has sparked debate due to its possible socio-political implications.
One of the most frequently cited concerns is the risk of abuse in the context of regulation or censorship. The idea is as follows: if Bitcoin were to allow the restriction of output destinations, could a government or large corporation exploit this to impose constraints? For example, a hypothetical scenario involves address whitelisting: an exchange or custodian could enforce customer withdrawals into CTV scripts that only allow spending to a set of “authorized” addresses (e.g., KYC-verified or regulator-approved).
In such a case, bitcoin withdrawn from that exchange would be marked: if you tried to send them elsewhere, the transaction would be invalid under the covenant—unless the recipient was on the whitelist. This could undermine Bitcoin's fungibility, as some UTXOs would only be spendable to certain destinations, effectively becoming different “types” of bitcoin.
This scenario is taken seriously by the community, which values Bitcoin's fungibility and neutrality. However, it's crucial to note that CTV, by design, does not allow recursive covenants: it is not possible to impose restrictions that persist indefinitely from transaction to transaction.
A truly effective censorship mechanism via whitelist would require each successive output to remain constrained—a kind of infinite covenant. CTV, on the other hand, only allows you to constrain the immediate next spending transaction, after which the constraint disappears. Therefore, even if an exchange used CTV to restrict withdrawal outputs, the user could always spend that constrained transaction and regain full control in the next hop.
Additionally, the CTV episode has already impacted Bitcoin’s upgrade process on a political level. The Speedy Trial versus organic consensus debate highlighted two schools of thought: one more eager to innovate as improvements become ready, and another more conservative, preferring protocol changes only in cases of pressing necessity—and ideally grouped under fewer, broader soft forks. The latter perceived CTV as non-urgent and potentially premature.
The situation also raised questions about who decides, and how, whether sufficient consensus exists. Unlike Taproot, where support was nearly unanimous, consensus for CTV in 2022 was ambiguous: many developers supported the idea but were hesitant about the timing; others objected to the timing but not the concept. In the absence of overwhelming consensus, pushing for activation is rightly seen as counterproductive.
As of now, CTV remains on hold, but it is not excluded that—perhaps in a slightly modified form—it could eventually find its place in the Bitcoin protocol.
