Covenants & CTV: What they are, how bitcoin custody might benefit, and risks to consider

Covenants have become a hot topic recently in bitcoin tech- and product-level discussions. For many who are relatively new to the space or don’t have the time to delve deep into mailing list discussions, covenants can feel like an abstract, unexplored, and even unnecessary topic. In reality, they have quite a long and rich history of research and offer some exciting benefits if implemented correctly. There are risks to consider, however.

There’s a lot to cover on this topic. If you’d like to jump around, here’s the road map of what we’ll be discussing:

• History of covenants research in bitcoin
• What is a covenant?
• How does CTV work?
• Covenants and custody
• Risks and concerns
• Conclusion and next steps

History of covenants research in bitcoin

In one of the first mentions of the topic back in 2013, Gregory Maxwell described an early iteration of bitcoin covenants as “an amusingly bad idea.” But they later started to be taken more seriously. An IRC chat from 2014 between several prominent developers includes a discussion of the feasibility of covenants, and a paper by Möser, Eyal, and Gün Sirer titled “Bitcoin Covenants” was published and presented at Scaling Bitcoin in 2016. These efforts started to look more seriously at how covenants could be built in bitcoin and explicitly how they could benefit bitcoin custody (we’ll get into that more in a bit).

More recently, in 2020, Swambo, Hommel, McElrath, and Bishop’s paper Custody Protocols Using Bitcoin Vaults further outlined how to build vaults that mimic some of the functionality brought by covenants (with some security trade-offs). There has since been a myriad of different proposals that enable covenants in some form in bitcoin script: OP_CHECKSIGFROMSTACK (CSFS), SIGHASH_ANYPREVOUT (APO), OP_TAPLEAFUPDATEVERIFY (TLUV), OP_EVICT, OP_CAT, OP_TXHASH, and OP_CHECKTEMPLATEVERIFY (CTV), to name a few.

As it is amongst the oldest (in development since mid-2019), most mature, and most researched of the proposals, most of this discussion will be focused on CTV-style covenants.

To be clear, individuals at Unchained Capital take a diverse range of positions both on the advisability of a CTV soft fork and on its path towards possible activation. As such, this article by no means represents Unchained Capital the company taking a stance on either question.

Okay, but what is a covenant anyway?

Let’s start with a “normal” bitcoin transaction. In all situations, your bitcoin is protected with a locking script. In order to spend these coins, you must be able to satisfy the conditions of this locking script. The most common case would be: “You cannot spend this coin without a signature that proves you have the private key that matches this public key”. The public key is basically the locking script, and the signature with the matching private key unlocks it. And of course, there are some slightly more complex locking conditions such as: “This coin can’t be spent until after X number of blocks” (timelocks), “This coin can’t be spent unless 2 out of 3 of these keys sign” (multisig), etc.

The word covenant originates from law, which defines a covenant as:

A formal agreement or promise, usually included in a contract or deed, to do or not do a particular act; a compact or stipulation made in writing or by parol.

An example of a legal covenant would be one attached to the purchase of a house. We most commonly see this with HOA agreements, where you might agree to not paint your house a particular color, for example. So you gain ownership of the property but are restricted in what you can do with it.

So whereas in a “normal” bitcoin script, we only require specific conditions to be met to unlock a particular script (sign a transaction with a private key, for example), in a covenant, the script is restricting what you can do with that coin (or where a coin can be spent to). As the Swambo, Hommel, McElrath, and Bishop paper puts it, a covenant is “a mechanism to enforce conditions on future bitcoin transactions”.

So how does CTV enable covenants?

CTV is the result of a long process of trying to develop a “Minimum Viable Proposal” for covenants—one which would satisfy a basic set of functionality while avoiding many of the risks that might arise from more general covenant designs (see the section below for more discussion of risks related to overly general or recursive covenants). The result of this work, led by developer Jeremy Rubin, was CTV, which stands for “Check Template Verify.”

Simply, CTV commits, or locks, a UTXO to a “template” of the transaction that can spend it, describing the specific circumstance in which the UTXO can be spent. Here, template has a precise meaning: The hash, or fingerprint, of a specific subset of the future transaction’s fields.

Where a “normal” bitcoin locking script might say, “this coin can only be spent if signed with this private key,” a CTV locking script might say, “this can only be spent if it is the input for a transaction matching this specific, narrow template” (or, more literally, matching a hash of a subset of the future transaction data). Just as a legal covenant can restrict the sale of a house to a specific person or constrain what you can do with a house once purchased, a CTV covenant can restrict the use of a coin to a specific future transaction that can spend it.

On its face, this characteristic might sound anywhere from superfluous to downright dangerous (why would I want to restrict what I can do with my bitcoin??), but there are some really nice implications of unlocking this functionality, especially when it comes to self-custody. And if designed carefully, a bitcoin covenant can likely do so without exposing any additional concerns or costs than exist today.

Covenants and custody

There are many proposed applications for a CTV-based covenant:

• Scaling bitcoin transaction capacity
• Congestion control
• Efficient DLCs
• Trust-minimized loans
• On-chain derivatives
• Lightning channel factories
• And more

That a narrow restriction on coin use can add so much functionality may be unintuitive, but is perhaps most easily explained by thinking of covenants as a tool for delayed execution. Covenants allow you to create and confirm transactions that do specific things and then delay the actual execution of that functionality to an arbitrary point in time (in computer science terms, this can be thought of as a “thunk“).

Broadly speaking, committing to future transactions seems so useful to me at this point that I’m starting to wonder why it isn’t dead obvious to everyone (including me in the past).

— Keags 🏛 – BIP-119 (@ProofOfKeags) January 28, 2022

The idea here is that computation is suspended in the sense that evaluating the entire contract resolution path hasn’t happened yet. You can lazily advance state as needed.

— Keags 🏛 – BIP-119 (@ProofOfKeags) January 29, 2022

The wide world of vaults

One use of this “delayed execution” capacity offered by CTV is “vaults.” Vaults are a pretty overloaded term in this industry (we even call our own collaborative custody product a “vault”). Generally they can be thought of as encompassing the area of development facilitating self-custody while sacrificing as little security and usability as possible. They are a useful vehicle for this discussion because they are simultaneously powerful, simple enough to grasp without much technical background, and provide immediate value to an Unchained user base. Vaults also happen to be the originally conceived use case for covenants.

One of our goals as a company is to help as many people as possible self-custody their bitcoin. Self-custody reduces reliance on centralized third parties like exchanges or custodial wallets, something we consider a core value of bitcoin and which increases our clients’ financial self-sovereignty while strengthening the ecosystem by reducing the possible impact of central points of failure. In our opinion, 2-of-3 multisig and collaborative custody are the best vehicles to achieve this given the tools available today.

When we onboard new users, we take great care to educate them on security best-practices: how to generate seeds, how to verify addresses, how to store backups and devices securely and in geographically distributed locations, etc. When you are self-sovereign and responsible for  generational wealth, you want to maximally reduce the risk of both theft and loss. There is no bailout for lost or stolen keys, and remember that in a world without covenants, the only lock on your keys is the specific conditions encoded in the locking script. If an attacker gets the means to satisfy the script, e.g. gains access to your keys (or you lose them), you no longer fully own the means of unlocking them.

This highlights some of the tradeoffs with multisig. For one, the more securely you’ve stored your keys and seeds, the harder they are to reach in an emergency. In addition, a savvy attacker targeting your funds can hide the fact that they have access to your keys until the transactions have already been signed and the bitcoin stolen.  As a result, many who value the security of geographical distribution will still likely pick convenience over security. We know this is true because most people still use single signature setups or, even worse, centralized custodians, despite companies like Unchained and Casa making multisig easy for the average user. This is not just because of convenience but also because complexity can present a greater risk to loss of funds than theft or seizure for most.

Simulating covenant-enabled vaults

So, how can we improve on the multisig custody status quo with covenant (or covenant-like) vaults? One way to think about the goal is that you may want a way to spend a portion of your funds with less friction (e.g., with a single signature, perhaps hot wallet), but without putting all of the funds at risk or the ability to back out of a transaction if it represents a possible theft.

In the original Custody Protocols Using Bitcoin Vaults paper, the proposal uses a clever graph of timelocked and presigned transactions that effectively enables this functionality. A demo of the system has been written in Python by paper co-author Bryan Bishop.

Functionally how this works is a system built around two main stages (which can themselves be sharded to go many levels deep as shown above):

1. Vaulting stage: locking UTXOs with a key that must be provably destroyed.
2. Unvaulting stage: before destroying the key, you will presign unvaulting transactions with it. Unvaulting involves publishing the presigned transactions. Typically the unvaulting transaction will have at least two spending paths: some of the funds can be spent with a hot key after a timeout, and the rest are “re-vaulted.” There can also be a recovery path if you did not mean to unvault.

Alongside the vault, a system also watches for unvaulting transactions. When one is seen that you have not told the watchtower about, the system is empowered to issue a P2RW (push to recovery wallet) transaction in order to prevent the thief from spending it using the hot wallet key they stole from you. If you did authorize the transaction, the output can be spent after the timelock with your hot wallet key.

From the original paper: “A vault transaction has two possible spending paths; it can be accessed by the active wallet only after a time-lock has expired or the P2RW transaction removes the possibility of the active wallet accessing ‘vaulted’ funds and ensures only the recovery wallet can access them.” This allows us to have a way to “back out” of a possible theft attempt when detected.

One major downside of this approach is the reliance on a key that presigns the transactions and the requirement to prove that the key has been destroyed, which is not believed to be possible. If this key is recoverable in any way, that means that the UTXOs can be double spent, effectively undermining all security guarantees of the system. Having a covenant system that lets us pre-commit to the transaction that will spend the UTXOs lets us shortcircuit this concern. It also lets us program much more complex graphs of transactions such as that diagrammed above in a much safer way.

An example CTV-powered vault

To understand how CTV helps us model these types of custody systems, bitcoin core developer James O’Beirne has developed a “simple vault” program using CTV that can be deployed in a live testing environment (see Simple CTV Vault).

In human-readable terms, this process looks approximately like:

1. Send the coin you want to vault to a CTV-protected script that pre-determines and guarantees how this UTXO can be spent. It is guaranteed because it is committed to the blockchain rather than relying on an assumption of security of a presigned transaction.
2. Keep a copy of the “unvaulting transaction.” This transaction can be broadcast to move your funds into a liminal state, where they can either be spent after a predetermined timelock by a hot wallet or immediately “clawed back” into a cold recovery wallet if the unvaulting is fraudulent or mistaken.
3. Sometime in the future you’re on vacation and realize you might need to top up your travel funds.
4. Publish the unvaulting transaction, which unlocks your funds for spending by your hot wallet after a delay.
5. In the case where you didn’t mean to publish this transaction, perhaps an attacker is trying to steal your funds after getting access to your hot wallet keys, you have the amount of time in the delay to get to your cold wallet keys (maybe travel to one of your geographically distributed keys and rely on Unchained for the other signature) and make sure that the hot wallet key can’t be used to spend the funds.

Potential advantages of CTV vaults for self-custody

The above is just the simple vault construction, but it helps to give a good idea of what CTV enables and how it could be extended.

Features of a CTV-powered vault

• Trust minimized: You can trust an entity, like Unchained Capital, to create this vault for you without having to trust us to destroy any keys used to pre-sign transactions, and easily verify the spending conditions.
• Watchtowers: With the ability to minimize downside risks, you can trust a third party to act as a watchtower for you such that you are alerted immediately once the unvault transaction has been detected on the blockchain. If the watchtower service is also a key holder in your cold storage setup they can be ready to sign for your recovery transaction signing.

Extensions on the simple vault model

Building on the above setup with more complex vaults, we can get additional benefits:

• Limit impact of breaches: Rather than have your vault commit to spending all of the funds via the hot or cold keys, you could lock-in a spending condition such that only a percentage of funds can be stolen in the worst-case scenario (which Bryan Bishop demonstrates with CTV here). So the unvaulting transaction would have, for example, 10% of funds spendable by hot key after a timeout or with cold keys immediately, and the other 90% goes back to another CTV protected vault transaction with the same conditions. A nice feature of this too is that you can be alerted to compromised keys without having all funds put at risk, effectively serving as a honeypot.
• New business models: You can build trust-minimized business models around recovery services such that you can securely pre-commit to a percentage of funds going to a signing service only if you require their signature. One advantage of this is that there is a reduced risk of a company going rogue or going out of business and holding your funds hostage if you require their signature.
• More complex spending conditions: Combined with taproot, you can program more complex spending conditions that remain private unless you absolutely require them or in the case of musig signature aggregation remain private if you need to do a recovery with your cold keys. You can also hide CTV unvaulting in a tapscript leaf, such that the CTV vault is basically your emergency spend when you don’t have access to your keys.
• Conditional spends with DLCs: DLCs allow you to non-interactively use 3rd party oracles to pre-program in spending conditions tied to external scenarios, such as changes in price. So, for example, you could create a “Laser Eyes HODL Vault” that only lets you spend a portion of funds if the price of bitcoin reaches $100k. There are also some really nice applications of this feature for loans.

Risks and concerns

There are two categories of concerns regarding CTV that are worth highlighting. The first is with covenant design generally and the second is with the CTV implementation specifically.

General covenant concerns

1. Recursive covenants and Turing completeness

Covenants designed in a certain way could be so general that funds could potentially be encumbered forever with no way to unlock them without a hard fork. There are additional related concerns about recursive covenants. These could involve bitcoin script essentially “calling itself,” which is much harder to model, and makes the risks and costs of a given transaction harder (and in some cases impossible) to calculate. In addition, they could conceivably impose additional, potentially unbounded validation costs on the rest of the network.

There doesn’t seem to be a consensus in the developer community about whether or not recursive covenants should be a concern for bitcoin. Part of the argument includes that you can already lock up funds forever (boating accident anyone?) and that the costs of infinite loops are already bounded by transaction costs, since they can only recurse across transactions (which is different than in a system like Ethereum for example). This is still very much a live debate however, as can be seen in this bitcoin developer mailing list thread started in February, 2022: Recursive covenant opposition, or the absence thereof (which includes responses expressing opposition).

Because this is a live concern, CTV was purposefully built to be strictly enumerable (not recursive), i.e., a graph of connected CTV transactions MUST end eventually, and can be verifiably proven to have this property.

2. Blacklisting and fungibility

This is really a subset of the above concern and has been around for a while. It was discussed originally in the 2013 Greg Maxwell forum post linked above and has recently been revived in the debates around CTV activation, notably in a video by long-time bitcoin educator Andreas Antonopolous. The idea is that if you can lock up where a bitcoin can be spent to, a government actor could force exchanges to only withdraw to covenants where they have some control over the coin.

This is generally believed not to be a concern anymore since this same risk already exists today. If a government can control where you send your bitcoin, it can control how you spend your bitcoin. The covenant risk is fundamentally the same as a government saying exchanges can only send to addresses that have a taproot spend path or multisig controlled by the government (something like the Silent Payment construction could work for effective surveillance). The concern has been broadly dismissed by bitcoin developers, e.g., in this IRC chat from 2014.

CTV-specific risks

The BIP (Bitcoin Improvement Proposal) for CTV does a good job describing the design tradeoffs and risks of this particular covenant proposal (many of which can apply to other covenant designs as well). There are three primary concerns that are worth discussing here:

1. CTV is not general enough

The disconnect between those who want very narrow functionality in covenants and those who believe general functionality and even recursion are desirable make this a very tricky challenge to navigate. On the one hand, some believe that we shouldn’t have CTV until we have more powerful, general designs and that activating now on the network would add unnecessary code bloat that we would have to maintain. The problem here is that some (as noted above) don’t think we should have general covenants at all, so it’s not clear that waiting for these designs and research will ever actually yield the functionality. The BIP does, however, outline future upgrade paths if we do want to add more functionality including a versioning system and composability with other possible future opcodes.

2. Footguns

The concern with footguns is that CTV makes it too easy for a user to lose funds if it’s not used precisely in the way it’s intended. One of the biggest risks is that CTV templates lock you into how much you will spend in the future transaction. So if the input value is too high, excess funds get “donated” to miners in the form of fees, and if the value is too low the UTXO becomes unspendable since there is not enough to fund the outputs in the committed-to transaction.

This risk can be mitigated by having a spend condition that is very secure and only to be used in emergencies (e.g. a 3-of-3 with keys that are buried under ground in different countries). In fact, risks like this exist today particularly in off-chain protocols where you commit to amounts (like in Lightning or the 2020 vaulting proposal). Ultimately this is a problem with UX design and avoiding address reuse. There are also future upgrade paths such as with CTV versions or other opcodes, like OP_AMOUNTVERIFY that could be used to avoid these footguns.

A similar footgun, with similar solutions, is permanently unspendable outputs where the CTV template is somehow malformed and so can never be satisfied. This is also possible today if you send to an OP_RETURN address or to a “burn” address like 1BitcoinEaterAddressDontSendf59kuE.

3. Fee management

This is a category of problem that exists in many off-chain and contract protocols in bitcoin due to how the fee mechanism is designed. When you commit to a future bitcoin transaction, like with Lightning channels or a CTV transaction, the challenge is you don’t know what the fee market will look like when you want that transaction processed. Since fees are paid within that transaction you are committing to, however, that means you have to try and guess how much to pay in fees before you need to spend it. The current best practice for avoiding this is to include a CPFP (Child pays for parent) anchor output in the transaction so that you can “bump” fees if necessary in the future. There are also proposals for how to solve this problem more effectively, such as with fee sponsorship but would require their own soft fork to activate.

It is important to note that the more general covenant proposals don’t suffer from this as much, particularly in those where there’s flexibility around the inputs for the spending transaction.

Regarding activation

When writing this article, I’ve explicitly avoided discussion of proposed CTV activation methods. Evaluating the technical merits of a bitcoin improvement proposal is a different topic from activation. The risks of CTV and covenants are a separate matter from the risks of activation, which can equally apply to many other past and future proposals.

Conclusion and next steps

What we’ve laid out above is a practical framework to evaluate some of the technical functionality that covenants could bring to bitcoin’s self-custody toolbelt. We’ve looked at the historical context in which the discussion of this technology has occurred, the current state of affairs when it comes to custody, and what gaps exist that covenants might help fill.

Multisig, collaborative custody, and tools that help support a robust ecosystem around them such as Hierarchical Deterministic Wallets, hardware signing devices, PSBT, and descriptors have all been important advances in making bitcoin the greatest store of value and best form of sovereign money the world has ever seen. Understanding if and how those properties can be improved upon is an important part of protecting our bitcoin for future generations, even if the right solutions to those problems are still up for debate.

Vaults are also only the tip of the covenant iceberg. If you’d like to continue learning more about covenants and CTV, there are a lot of resources to sift through. The original covenant papers cited in this post are a good place to start, particularly if you want to learn more about the vault and custody applications. Additional resources include:

• The official CTV Bitcoin Improvement Proposal: BIP 0119
• The code implementation to introduce the functionality into bitcoin core
• Start playing around with CTV contracts on the live signet (a testing network that lets you try out new features or applications)
• More resources can be found on utxos.org, an advocacy site for CTV

Evaluating the value add of a particular technical upgrade to bitcoin is just one step in the process, and one every engaged bitcoiner should spend time educating themselves on as much as possible.