Important: everything on this page describes proposals. As of October 2026, none of these opcodes is active on Bitcoin. Activating any of them would require a soft fork.
What is a covenant?
Today's Script controls who can spend a coin. A covenant would also control where it can go: to a specific set of outputs, or only to a vault after a delay. Pre-signed transactions can imitate some of this, but they require trusting that a key was deleted, or a lot of interaction.
CTV – OP_CHECKTEMPLATEVERIFY (BIP119)
Proposed by Jeremy Rubin, CTV would redefine the unused OP_NOP4 opcode. A script holds a 32-byte hash, and the spending transaction must match it. The hash commits to the transaction's version, locktime, number of inputs, sequences, outputs and the input's index, so the coin can only be spent in one pre-agreed way. CTV is deliberately limited and cannot express recursive rules. Its status in the BIPs repository is Draft.
OP_CAT (BIP347)
OP_CAT joins two stack items into one. It existed in Bitcoin's early days but was disabled in 2010. BIP347, by Ethan Heilman and Armin Sabouri, would bring it back in Tapscript only, by redefining OP_SUCCESS126 with the original opcode value 0x7e, limited to 520-byte results. Combined with Schnorr signature tricks, it can be used to inspect the spending transaction and build covenants, as well as other tools such as Merkle proofs. The BIPs repository lists BIP347 as Complete. That means the specification is finished. It does not mean it is activated.
Other proposals
- OP_CHECKSIGFROMSTACK (BIP348, Draft): check a signature on any message, not just the transaction. Often proposed together with CTV.
- OP_CHECKCONTRACTVERIFY (BIP443, Draft): by Salvatore Ingala, for passing state between outputs, aimed at vaults and smart contracts.
What they could enable
- Vaults: stolen keys could only move coins into a timelocked path that the owner can cancel.
- Congestion control and batching: commit to many payments with one small output and expand them later.
- Layer 2: more efficient Ark, channel factories and Lightning designs.
The debate
Supporters point to security and scaling benefits. Critics worry about recursive covenants that restrict coins forever, new forms of miner incentive problems, and the risk of choosing the wrong design, since consensus changes are hard to undo. There is no agreed path to activation. Treat any claim that a covenant "is coming" on a fixed date as speculation.