Covenants and vaults: CTV, OP_CAT and the 2026 debate

Wonder

1. Why can a standard Bitcoin script verify who holds the keys but not where the coins go next?
2. What specific constraints does OP_CHECKTEMPLATEVERIFY impose on future transactions?
3. Why would re-enabling a single concatenation opcode, by soft fork, open the door to covenants?

Explore

Part ICovenant proposals: CTV and OP_CAT

1. Standard Bitcoin scripting verifies ownership of a key or hash, but it cannot restrict where the coins go after unlocking. A covenant changes this by imposing conditions on the `scriptPubKey` of descendant outputs. This mechanism is often compared to meal vouchers: unlike cash, which spends anywhere, these funds are restricted to specific partner restaurants. Proposed uses include vaults with delayed withdrawal paths, congestion control, and simpler Lightning designs.
2. Jeremy Rubin proposed OP_CHECKTEMPLATEVERIFY (CTV) in 2019. This opcode embeds a hash of a future transaction template into the current UTXO. To spend it, the spending transaction itself must match this exact template; no signature is involved in the verification step. It pins the next move before executing the current one. Any deviation in amounts, destinations, or script structure causes the validation to fail immediately, ensuring strict adherence to the predefined path.
3. CTV’s limitation is rigidity: the next transaction’s outputs are fixed when the coins are locked, so fees must be handled another way, for example with an anchor output and child-pays-for-parent. In exchange, CTV is simple to analyze and cheap to validate.
4. OP_CAT, an opcode that concatenates two stack items, was disabled by Satoshi Nakamoto in 2010 as a precaution against memory-exhaustion attacks. BIP347 proposes re-enabling it specifically within tapscript. Combined with Schnorr signature tricks, OP_CAT enables covenants and other complex logic without requiring new consensus rules for every specific use case. It provides a primitive building block that developers can combine to create bespoke restrictions on future transactions.
5. Related proposals include OP_CHECKSIGFROMSTACK (BIP348), which verifies a signature over an arbitrary message supplied on the stack rather than over the spending transaction. This flexibility, combined with CTV (or, separately, the proposed ANYPREVOUT), would enable symmetric Lightning channels where neither party needs to store penalty data for every old channel state.
6. As of 2026, none of these covenant proposals have been activated, though activation efforts and argument continue. The debate continues over their usefulness, the risk they add to consensus rules, and the governance process required for activation. The expansion of consensus rules introduces questions about network complexity and long-term maintainability that remain unresolved in the community.

Part IICovenants and vaults: the debate in 2026

7. Bitcoin scripts currently verify conditions on the current transaction, such as signatures or lock times. They cannot inspect the outputs of the spending transaction. Covenants extend this scope: a scriptPubKey can impose constraints on the scriptPubKey of the outputs created by the transaction that spends it. This restricts where coins can go next, enabling features like address whitelisting and non-interactive payment channels.
8. BIP-119 proposes OP_CHECKTEMPLATEVERIFY (CTV). It allows a script to embed a template hash; the spending transaction must match this template in its outputs, input count, sequences, locktime and version, though not in which inputs are spent. CTV is non-recursive, meaning it constrains only the immediate next step. It replaces OP_NOP4 and requires a soft fork. It can underpin ‘vaults’, which add a time delay to theft recovery.
9. In a vault, withdrawals must pass through a waiting period (for example 12 hours) during which a separate recovery key can sweep the funds to safety. If an attacker steals the everyday key and starts a withdrawal, the owner sees it on-chain and claws the funds back before the delay ends. This turns key theft from irreversible loss into a recoverable event, provided the victim monitors the chain.
10. Despite discussion since 2013, no covenant soft fork has activated. Taproot (November 2021) remains the last major upgrade. In February 2026, an activation client for BIP-119 was published without Bitcoin Core involvement. It requires 90% miner signaling between March 2026 and March 2027. As of May 2026, signaling remained near zero, indicating no consensus on adoption.
11. OP_CAT (BIP-347) reached complete specification in March 2026 but lacks activation parameters. It enables concatenation of script elements, allowing more complex logic than CTV alone. CTV is often paired with CheckSigFromStack (CSFS), which verifies a signature on arbitrary data from the stack, not only on the spending transaction. Together, they offer significant expressiveness gains for smart contracts and protocol design.
12. The debate centers on trade-offs: covenants enhance security and enable new protocols like vaults, but introduce complexity and governance risks. A soft fork changes consensus rules, requiring broad miner and node operator agreement. The current stagnation reflects caution about implementation bugs and the irreversibility of chain state changes. Users must weigh these gains against the risk of a failed or contested activation.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• J. Rubin, OP_CHECKTEMPLATEVERIFY (BIP119), 2019-2020
• BIP347: OP_CAT in Tapscript (E. Heilman & A. Sabouri, 2023)
• BIP348: CHECKSIGFROMSTACK (B. Black & J. Rubin, 2024)
• Bitcoin Optech, 'Covenants' topic guide
• J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• Delving Bitcoin activation discussions (2026)