Contents
For almost as long as Bitcoin has been around, Bitcoiners have debated changes to Bitcoin Script in order to add more functionality and programmability at the core protocol level. That programmability enables more complex use cases and makes the Bitcoin chain more viable for all kinds of applications. One approach to adding this functionality, known as Bitcoin covenants, would require adding new opcodes, or re-introducing previously deprecated opcodes.
Adding opcodes has been hotly debated because while it may unlock better UX for Bitcoin and many more use cases, it increases the complexity of Bitcoin. That complexity makes Bitcoin more vulnerable to attacks and could undermine the security and simplicity that have made Bitcoin so popular in the first place.
Covenants also introduce potential fungibility issues with sats (sats associated with a particular covenant may be valued more highly (or less) than other sats). That impact on fungibility could hurt the effectiveness of Bitcoin as a currency or payments system, which adds another point of contention to the great covenant debate.
What Problems Do Bitcoin Covenants Solve?
Before we look at specific covenant proposals, let’s take a step back to better understand the problem covenants are trying to solve in the first place.
Covenants are important for using Bitcoin in a self-custodial manner, meaning using Bitcoin without trusting a third party application or protocol to custody your Bitcoin. Because Bitcoin uses a UTXO model to track balances and transactions, it is harder to build self-custodial solutions than it is on an account-based chain like Ethereum. Covenants ease that difficulty and enable benefits like a better user experience, faster transaction times, and more functionality, all without trusting another person or entity to hold (custody) your Bitcoin in exchange.
More specifically, covenants would enable developers to add conditional logic to how Bitcoin can be spent, and that logic would be enforced at the protocol level, without some other intermediary in the middle policing it.
There are countless possible use cases for covenants, here are two concrete examples:
- Vaults: One practical application of covenants is the concept of “vaults” that allow you to deposit BTC into a smart contract-like structure (the vault) that has rules associated with how the deposited BTC can be transferred.
- Spending Conditions: Whitelisting addresses (only approve transfers to specified addresses), time-locks (only approve transfers after a set period of time) or setting spending limits (only approve transfers under a certain amount).
A Technical Breakdown of Covenants
In more technical terms, covenants are spending conditions attached to Bitcoin transaction outputs (UTXOs) that restrict how the recipient can spend the sats associated with that UTXO. Unlike regular Bitcoin transactions where recipients have complete freedom over how they use received funds, covenants allow senders to impose specific constraints on how the sent BTC can be spent in the future without requiring pre-signed transactions or ongoing coordination between parties.
There are two main types of covenants:
- General covenants which can be replicated indefinitely and don't expire after spending. General covenants could be useful for whitelisting addresses, where sats can only be sent to and from pre-approved addresses. You wouldn’t want this condition to expire after one transaction.
- Pre-computed covenants which can only be replicated a limited number of times and have pre-defined conditions. Pre-computed covenants could be helpful when interacting with DeFi applications, like when you want to trigger a certain action at a specific price or block height.
Covenants are one of many scaling solutions builders have brought to Bitcoin along with side-systems or layer 2s like Stacks. We believe Bitcoin needs as many scaling solutions as possible. Why? Because it simply won’t scale to a billion users without them.
Over its 15 year lifetime, the Bitcoin network has already undergone massive changes such as SegWit and Taproot. It’s entirely possible that Bitcoin’s next big upgrade brings with it covenant functionality.
Top Covenant Proposals
There are nearly a dozen BIP proposals related to covenants and vaults. All of them require introducing or reactivating an opcode, which is the basic operation function of Bitcoin Script. These proposals range from conservative to absolutely based, in terms of how much new functionality would be introduced at the core protocol layer. Any covenant proposal would require a Bitcoin soft fork, which is a backwards-compatible consensus change to the Bitcoin core protocol. However, Bitcoin consensus changes are notoriously hard to coordinate, often taking years of research and debate before going into effect.
In the past few months, several proposals have risen above the rest in terms of community support and traction. The two most popular proposals are OP_CTV and OP_CAT.
What Is OP_CTV?
Of the popular proposals, OP_CTV is the least flexible in terms of programmability and functionality, and therefore is regarded as the most safe and less likely to introduce negative externalities and risks to Bitcoin.
OP_CTV (short for CHECK-TEMPLATE-VERIFY) is a Bitcoin Improvement Proposal (BIP 119) created by Jeremy Rubin in 2020. With OP_CTV, you ****make an un-broadcasted transaction (the template), then you apply that as a rule for future spending of specific UTXOs. In order for the future transaction to be valid/ approved by miners, they would have to check that template and verify (hence the name) that the pending transaction matches the template. Only if that condition is satisfied would the miner then approve the transaction. OP_CTV is very similar to a pre-signed transaction, but without exposing signing or private keys, which is a big benefit.
OP_CTV focuses on enabling pre-computed covenants rather than general covenants, which allows for complex transaction designs while maintaining Bitcoin's security and decentralization properties. OP_CTV is frequently mentioned alongside another opcode OP_CSFS (CHECK-SIG-FROM-STACK) in order to unlock its fullest potential.
How does OP_CTV Enable Covenants?
OP_CTV enables covenants by incorporating a commitment hash into the locking script of a transaction output. This hash represents specific spending conditions that must be met for the output to be spent.
For example, in a vault implementation, a user could create a transaction that locks funds for a specific time period, restricts where those funds can be sent, or creates backup recovery paths if theft is detected. Once broadcast, these conditions are immutable.
OP_CTV eliminates the need for pre-signed transactions that must be stored off-chain, making covenant implementations more scalable and reducing the need for interactivity between all parties when funds are eventually spent.
What is OP_CAT?
On the opposite end of the spectrum from OP_CTV, OP_CAT is the most broad covenant proposal, in terms of how much functionality it potentially introduces to Bitcoin. CAT stands for concatenate, which would enable devs to combine two existing opcodes in a single script program. This might not sound exciting, but it would enable you to do a lot of crazy stuff on Bitcoin. OP_CAT is very simple code, but it’s implications are complex and hard to model out, making it one of the riskier opcode proposals.
OP_CAT is a Bitcoin Improvement Proposal (BIP 347) written by Ethan Heilman and Armin Sabouri in 2023. It proposes reintroducing an opcode that Satoshi Nakamoto originally disabled way back in 2010.
OP_CAT allows the concatenation of two data elements at the top of Bitcoin's script stack, combining them into a single, larger string of bytes. This deceptively simple function addresses a fundamental limitation in Bitcoin Script by enabling the compression of script elements and allowing large and small scripts to interact effectively. OP_CAT can emulate arithmetic and multiplication features, enabling more complex scripts without writing data-intensive code that could introduce bugs.
OP_CAT has risen in popularity thanks largely in part to a motley crew of Taproot Wizards campaigning for its adoption.
How does OP_CAT Enable Covenants?
OP_CAT enables covenants by working with other opcodes, particularly in conjunction with Taproot's Schnorr signatures. More specifically it allows developers to concatenate script elements to create transaction hashes that represent specific spending constraints.
By itself, OP_CAT doesn't create covenants, but when combined with verification opcodes like CheckSig, it can constrain parts of a transaction (such as destination addresses or amounts) as requirements in the unlocking script. Unlike OP_CTV, which provides a self-contained solution for predetermined spending paths, OP_CAT serves as a foundational building block that, when combined with other opcodes, enables more flexible covenant implementations within Taproot transactions without introducing excessive computational overhead for node operators.
What Do Covenants Mean for Stacks?
Even if more functionality is added to the L1 via covenants, Bitcoin still needs a programmable layer. While OP_CAT and OP_CTV provide more robust functionality to Bitcoin, they are still limited and don’t add full smart contract capabilities like complex conditional logic or stateful applications that can respond to external data inputs.
For instance, with covenants, you couldn't build decentralized exchanges with automated market-making, lending protocols with automated liquidation, stablecoins that rely on algorithms to maintain their peg, or prediction markets that rely on real-world inputs. These kinds of apps require the ability to execute iterative calculations, maintain complex state between multiple users, and integrate with external price oracles. All abilities that covenants lack.
And at the same time, programmable layers like Stacks can only interact with Bitcoin in limited ways, and specifying conditions to send Bitcoin transactions in a self-custodial way is not something that sidesystems and L2s can easily do today.
Paired together, covenants and Stacks complement each other and enable more robust applications for Bitcoin. For example, covenants open the door for even more trust-minimized designs on Stacks, such as unilateral exit for sBTC. If sBTC were to potentially integrate covenants, specific conditions could be created so that even in the highly-unlikely scenario of the Stacks chain collapsing and miners and stackers going offline, a covenant could be put in place so that under those conditions (and only those conditions) users can directly withdraw their BTC from the threshold wallet itself.
Stacks’ smart contract language Clarity also has read-access to Bitcoin, so you can imagine that covenants and more robust functionality on the L1 could in turn lead to more sophisticated applications on Stacks that could take into account those covenant rules and build on top of them in a purely decentralized fashion.
Research on covenants is still ongoing, and no one can predict when the Bitcoin technical community will rally behind the next fork. What seems clear is that there is no silver bullet for scaling programmable Bitcoin to a billion users. It will take many communities of builders, approaching the challenge from different perspectives with different ideas. Ultimately, what’s good for Bitcoin is good for Stacks, and at Hiro, we’re firmly in the camp that Bitcoin should continue to innovate.
If you’re curious to learn more about covenants, check out these resources:
- The Great Script Restoration Project Talk by Rusty Russell at bitcoin++
- Covenants Bitcoin Optech
- Why bitcoin needs covenants by Jameson Lopp
- Are Covenants Necessary for Bitcoin? Stephan Livera Podcast
Special thanks to Kenny Rogers from the Stacks Foundation for his help in editing this post.
