Bitcoin Covenants: OP_CTV, OP_CAT, and the Future of Bitcoin Script
Covenants let Bitcoin transactions enforce conditions on how funds can be spent next. A clear explanation of OP_CTV, OP_CAT, and why they matter for vaults, scaling, and programmability.
Every Bitcoin transaction answers one question: who can spend these coins? The signature proves you are the rightful owner, and the network lets you move the funds wherever you choose. But what if a transaction could also answer a second question: how can these coins be spent next?
That is a covenant - a rule embedded in a transaction that restricts what future transactions can do with the funds. The concept has been discussed in the Bitcoin community since 2013, and it has become one of the most consequential technical debates in Bitcoin's history.
Why Covenants Matter
To understand why covenants are important, consider a problem that Bitcoin currently cannot solve elegantly.
You want to create a vault - a cold storage setup where, even if an attacker steals your private key, your coins are not immediately lost. The vault enforces a time delay: any withdrawal must wait 24 hours before the funds actually move. During that window, you can use a recovery key to claw the funds back to a safe address.
Without covenants, this is impossibly complex. The spending transaction has no awareness of what the next transaction will do. Your private key is a skeleton key - once compromised, it unlocks everything instantly.
With covenants, the vault becomes straightforward. The coins carry a rule: "the next transaction spending these funds must include a 24-hour timelock and must only send to one of these two addresses." The rule travels with the coins, not with the key.
This single capability - constraining future spending - unlocks an entire class of applications.
OP_CHECKTEMPLATEVERIFY (OP_CTV)
BIP-119, proposed by Jeremy Rubin, introduces the simplest possible covenant: a transaction can commit to the exact template of the next transaction that spends its outputs.
How It Works
OP_CTV takes a hash of a transaction template - the number of outputs, their amounts, their destinations - and locks the coins so they can only be spent by a transaction matching that template. Nothing else. No flexibility, no conditionals. The future transaction is predetermined.
Think of it like a check written to a specific person for a specific amount, with a note in the memo field that says "this person must then pay exactly $50 to Alice and $30 to Bob." The chain of payments is programmed in advance.
What It Enables
Congestion control - During fee spikes, an exchange could batch thousands of withdrawals into a single on-chain transaction that commits to paying each user individually later, when fees are lower. Users get cryptographic proof their withdrawal is guaranteed, even though the actual payment has not happened yet.
Simple vaults - OP_CTV can enforce the time-delayed withdrawal pattern described above. Not the most flexible vault design possible, but functional and minimal.
Non-interactive payment channels - Today, opening a Lightning channel requires both parties to be online and cooperate. OP_CTV could enable channel factories where a single on-chain transaction creates many payment channels at once, without requiring every participant to sign simultaneously.
The Tradeoff
OP_CTV is deliberately limited. It can only commit to one specific future transaction. It cannot inspect amounts, enforce complex conditions, or enable general-purpose computation. Proponents see this as a feature - minimal surface area means minimal risk. Critics argue it is too narrow to justify the complexity of a soft fork.
OP_CAT
OP_CAT is the oldest opcode in this debate - it was part of Bitcoin's original scripting language, and Satoshi removed it in 2010 over concerns that it could be used to create excessively large scripts. The proposal to bring it back, now as BIP-347, has reignited one of Bitcoin's most interesting technical arguments.
How It Works
OP_CAT does one thing: concatenate two byte strings on the script stack. Take element A and element B, push AB. That is the entire operation.
This sounds trivial, and in isolation, it is. But concatenation is a building block. When combined with Bitcoin's existing opcodes - particularly Schnorr signatures and Taproot - OP_CAT enables something remarkable: transaction introspection.
With OP_CAT, a script can reconstruct parts of the transaction that is spending the coins and verify that the transaction matches certain conditions. In effect, the script can "look at" the transaction it is embedded in and enforce rules about it.
What It Enables
General-purpose covenants - Unlike OP_CTV's rigid template matching, OP_CAT enables flexible spending conditions. A vault could allow withdrawals to any address, as long as the timelock is respected. A trust fund could release funds according to a schedule without predefining every possible recipient.
STARK verification - By enabling more complex computation in Bitcoin Script, OP_CAT opens a theoretical path to verifying cryptographic proofs on-chain. This could enable trustless bridges to other systems and advanced Layer 2 solutions that go beyond Lightning.
Recursive covenants - A covenant that can re-apply itself to the next transaction, and the one after that, indefinitely. This enables perpetual rules: "these coins can only ever move to addresses in this set" or "every time these coins move, 1% must go to this address." This is powerful and, to some, alarming.
The Controversy
OP_CAT's generality is precisely what makes it controversial. Recursive covenants could theoretically create permanent spending restrictions - coins that can never leave a certain set of addresses, or coins that enforce a royalty on every future transfer. Critics argue this undermines Bitcoin's fundamental property of fungibility: if some coins carry permanent restrictions and others do not, they are no longer interchangeable.
The counterargument is pragmatic: Bitcoin already has coins with complicated histories (coinjoined, from sanctioned addresses, recently mined). Perfect fungibility has never existed. And the utility of covenants - vaults, scaling improvements, new Layer 2 designs - outweighs the theoretical concern.
Other Proposals
OP_CTV and OP_CAT are the most discussed, but the covenant design space is broader.
OP_VAULT (BIP-345) - Proposed by James O'Beirne, this is purpose-built for the vault use case. Rather than providing a general-purpose tool, it introduces specific opcodes for time-delayed withdrawals with recovery keys. More complex than OP_CTV but more capable for its intended use.
LNHANCE - A bundle combining OP_CTV with OP_CHECKSIGFROMSTACK and OP_INTERNALKEY. The idea is that OP_CTV alone is too limited, but combined with these additional opcodes, it becomes powerful enough for most use cases without OP_CAT's open-ended flexibility.
OP_TXHASH - Allows scripts to hash specific fields of the spending transaction and verify them, enabling selective introspection. More targeted than OP_CAT but more flexible than OP_CTV.
The Governance Question
Covenants sit at the intersection of two tensions in Bitcoin's development culture.
The first is conservatism versus capability. Bitcoin's scripting language was deliberately kept simple. Satoshi removed OP_CAT for a reason. Every new opcode expands the attack surface and introduces complexity that must be maintained forever. The blocksize war taught Bitcoin's community that saying "no" to changes is sometimes the most important thing a decentralized system can do.
The second is ossification versus evolution. Some Bitcoiners believe the protocol should stop changing entirely - that the base layer should be frozen and all innovation should happen on higher layers. Others argue that carefully chosen soft forks can unlock enormous value without compromising Bitcoin's core properties, and that refusing all change is itself a risky choice.
Both positions have merit. Bitcoin's value comes from its resistance to change - from the fact that its rules are predictable and stable. But that stability must be balanced against the reality that better tools for self-custody, scaling, and privacy strengthen Bitcoin's core mission.
Where Things Stand
As of early 2026, no covenant proposal has reached the activation stage. The conversation continues across mailing lists, developer meetings, and community forums. OP_CTV has the longest track record of review. OP_CAT has the broadest theoretical capability and the most controversy. OP_VAULT targets the most immediately useful application.
The most likely path forward involves years of additional review, testnet experimentation, and community consensus building - the same slow, deliberate process that gave us SegWit and Taproot. Bitcoin moves slowly by design. When it moves, it tends to move correctly.
For those watching this space, the question is not whether covenants are useful - they clearly are. The question is which design best balances capability against risk, and whether the community can reach sufficient consensus to activate it. That process, messy and slow as it is, is Bitcoin governance working exactly as intended.