Bitcoin Covenants Part 1: Exploring New Possibilities for Complex Spending Conditions on the Bitcoin Network

Recently, the concept of so-called covenants has received renewed attention as Bitcoin development and protocol discussions underwent a renaissance. Covenants could enable and facilitate a wide range of applications, including new trustless and scalable layer 2s, fully non-custodial vaults with more complex spending logic, and more efficient payment channels. However, most paths to implementing this functionality require a soft fork of Bitcoin's consensus rules, a process that would likely spark debate within the community.

With the recent diversification of consensus clients into Core and Knots nodes, reaching agreement on such a change has become less likely. In spite of recently pushing for a soft-fork of their own, namely BIP-110, the Knots side tends to advocate for protocol ossification and appears less supportive of facilitating scaling solutions on the base layer. The recent controversy that Bitcoin Core has attracted, both as a technical debate and in governance, is diminishing the prospect of covenant implementations on Bitcoin anytime soon.

Prominent figures such as Michael Saylor have also publicly advocated for protocol ossification, portraying zealous, well-funded developers as the greatest threat to the protocol. Nonetheless, some minimal covenant implementation likely offers the most conservative path to trust-minimized Layer-2s, which can bring the privileges of self-custody to the next billion people. Should mainnet fees spike again in the future and a resolution to the spam wars is found,  discussions around these proposals are likely to regain momentum. In this article, we will lay some of the foundations for our readers to understand covenants. In follow-up pieces we will take a deep dive into individual proposals. 

To understand covenant proposals, it is necessary to grasp the basic validation flow for Bitcoin transactions. Bitcoin locking conditions are expressed in a stack-based, non-Turing-complete language called Bitcoin Script. The sender of a Bitcoin transaction specifies the spending conditions in this language by creating a so-called locking script (also known as scriptPubKey). When the recipient of the funds later wants to spend the outputs, they must provide the corresponding unlocking script (also known as scriptSig) that fulfills these conditions. Bitcoin’s scripting language can express a variety of validation conditions. It can verify public key signatures, enforce timelocks, verify hash preimages, and combine spending conditions with propositional logic. An entity with the correct unlocking script can move the Bitcoin to any arbitrary location, i.e., encumber them with any arbitrary scriptPubKey. However, it cannot put restrictions on where funds are sent after the correct scriptSig is provided.

It is this feature that covenants aim to enable. Covenants would allow users to impose restrictions on how coins can be spent in the future. The concept was introduced by Gregory Maxwell all the way back in 2013 to improve the scalability and flexibility of Bitcoin. It was later popularised by Möser, Eyal, and Sirer in 2016. Maxwell initially proposed using zk-SNARKs to impose spending restrictions. Since then, the discussion has seen an explosion of different proposals, culminating in some that may sidestep the requirement for a soft fork.

Basic (or precomputed) versus General (or recursive) covenants

A key distinction in covenant proposals lies between basic (or precomputed) and general (or recursive) covenants. In principle, basic covenants only impose restrictions on the next transaction in line. However, by chaining together encumbered addresses, basic covenants can also be used to define a finite sequence of transactions in advance. While this sequence of permitted transactions can be arbitrarily long or complex, it must be specified beforehand. 

General covenants would be able to express recursive spending rules directly within Bitcoin Script. This allows a spending condition to be reapplied indefinitely. For example, if Alice sent Bob 1 BTC, a basic covenant could ensure Bob can only send the funds to a specific address or encumbers it for a fixed number of steps. Under a general covenant, however, the UTXO worth 1 BTC would retain its same spending restrictions when Bob sends it to Steve, and again when Steve transfers it further, without any predefined endpoint. Although general covenants would offer greater versatility, they face significant technical hurdles and are viewed critically by the community. Their implementation would also require major protocol updates.

Proposed Covenant Implementations and Their Applications

Various implementation proposals and debates have shaped our understanding of how covenants could enhance Bitcoin’s functionality. To navigate this topic clearly, it is important to distinguish the proposed changes into four categories:

• Opcodes that fully implement covenant functionality. They directly impose spending restrictions on Bitcoin transactions. This includes OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT.
• Opcodes that serve as supporting tools. These extend the expressiveness of Bitcoin script or data handling but do not implement covenant functionality unless combined with other opcodes. In this category, we will discuss OP_CHECKSIGFROMSTACK and OP_CAT.
• Opcodes for specialized applications. We consider OP_VAULT, OP_UNVAULT and OP_EVICT.
• Proposals that approximate covenant behavior without a soft fork. These rely on cryptographic constructions within existing consensus rules or trust-minimized infrastructure rather than new opcodes. Within this category, we will discuss ColliderScript, Bitcoin PIPE and FE-based covenants. 

In our next article we will commence our discussion of the first category of covenant proposals by covering OP_CHECKTEMPLATEVERIFY — one of the most popular proposals so far.