The main focus of the discussion on Bitcoin’s next upgrade: what are the most relevant covenant proposals? What are the community’s positions?
The idea of implementing covenants on Bitcoin stems from the desire to expand the protocol’s use cases by applying restrictions to the scripting code. Essentially, covenants allow limitations not only on the immediate use of a UTXO but also on its future use. This functionality introduces new possibilities for applications related to security, scalability, and on-chain space management.
Covenant proposals have sparked widespread debate: on one hand, they generate optimism for their potential to enhance network scalability; on the other hand, they raise concerns about increased protocol complexity—which could introduce unknown risks—and the possibility of compromising Bitcoin’s fungibility in the long term.
Below is an overview of the most debated proposals.
CheckTemplateVerify (CTV)
CheckTemplateVerify (CTV) is a proposal introducing a new way to control how UTXOs can be spent in the future. In essence, CTV allows for the “pre-programming” of a sequence of transactions, defining exactly how the funds can move. This enables, for example, the creation of an address with specific conditions that dictate how the received UTXOs can be spent in predetermined ways.
It’s like setting a pre-determined path for bitcoins: once funds are deposited into a certain address, they can only be moved according to the initially defined rules. This increases the security and predictability of future transactions.
What does it enable?
CTV enables two new use cases:
- Security vaults:
Vaults are a type of covenant requiring two separate transactions, recorded in two different blocks, for a user to spend funds from their wallet. The first transaction serves as a signal that someone is attempting to spend the funds, giving the user the opportunity to block the second transaction, which is the one that completes the operation. - Timeout Trees/Channel Factories:
Timeout Trees are a system for organizing multiple payments efficiently. Starting from a single transaction, CTV allows for the automatic creation of a series of linked payments, resembling tree branches. Each branch follows specific rules and includes emergency exit options.
Additionally, CTV enhances Bitcoin protocols and applications that rely on pre-signed transactions.
CTV represents a trade-off between power and simplicity: it offers significant improvements while keeping complexity under control, though it sacrifices the flexibility of more advanced solutions.
ANYPREVOUT (APO)
ANYPREVOUT (APO) is a proposal that changes how Bitcoin transactions are signed. Unlike the current system, where each signature is tied to a specific previous transaction (UTXO), APO allows for the creation of signatures valid for any UTXO that meets certain conditions.
It’s like having a key that can open any door of a specific type, rather than a key designed for just one particular door.
What does it enable?
APO is primarily designed for two purposes:
- Improvements to the Lightning Network:
APO makes the Lightning Network simpler and more secure. Currently, when two users open a Lightning channel, they must manage multiple states and penalty systems to prevent fraud. APO simplifies this process: it makes channel updates easier, reduces the risk of losing funds due to technical errors, and improves backup management. - Eltoo Protocol/LN-Symmetry:
Eltoo is a new way of managing Lightning channels that becomes possible with APO. Today, if someone tries to use an outdated channel state, they lose all their funds as a penalty. With Eltoo, such a punitive system is no longer needed: old states are simply replaced by newer ones, making channel backups much simpler.
APO is focused on enhancing the Lightning Network. While it’s not a general-purpose solution for Bitcoin, it addresses specific issues with payment channels. Technically, APO can replicate the functionality of CTV, but with some significant drawbacks. This replication requires storing signatures and pre-signed transactions, making the process more complex and less efficient compared to CTV.
OP_CAT
OP_CAT is an operation that allows the concatenation of two pieces of information into one during the execution of a Bitcoin transaction. It’s like having an operator that takes two separate words and merges them into a single sentence.
What does it enable?
- Advanced smart contracts:
OP_CAT enables the creation of more sophisticated Bitcoin smart contracts. For example, it allows for the construction of multisig wallets capable of evolving their rules over time or vaults programmable with more complex conditions. While OP_CAT on its own has limited utility, when combined with Schnorr signatures, it facilitates the development of more advanced structures. Other covenant proposals also become more powerful and flexible when they can leverage the concatenation functionality provided by OP_CAT. - Simplified covenants:
OP_CAT makes it possible to create simplified forms of covenants—rules that control how bitcoin can be spent in the future. This opens the door to new applications for fund security and management without requiring additional changes to the Bitcoin protocol.
The flexibility of OP_CAT is also its main drawback, as it makes it difficult to predict and control all possible uses. Critics argue that some potential applications of OP_CAT may not necessarily benefit Bitcoin users and could lead to unforeseen and potentially harmful consequences for the network (e.g., drivechains or alternative projects that diverge from Bitcoin’s core principles).
TX_HASH
TX_HASH is a proposal aimed at filling a gap in Bitcoin’s scripting system: the ability to inspect and verify transaction details in a more granular way. While its technical utility is clear, particularly for advanced security applications, the complexity of its implementation may pose a barrier to its adoption.
TX_HASH is a tool that allows for reading and verifying the details of a Bitcoin transaction directly within a script.
What does it enable?
- Advanced verification:
TX_HASH allows transactions to be verified in new ways. A wallet can check not only who is spending the bitcoins, but also how they will be used in the future. - Intelligent vaults:
With TX_HASH, more sophisticated vaults can be built that can respond to different situations. For example, a vault could automatically freeze funds if it detects suspicious behavior or apply different rules depending on the type of transaction being attempted.
Comparison between CTV and TX_HASH
CTV and TX_HASH represent two different approaches to controlling future transactions:
- CTV is like writing a contract where every detail is specified in advance. It’s simple but rigid: everything must be planned ahead, and no changes can be made.
- TX_HASH is more flexible: it allows you to choose which parts of the future transaction to control. It’s like a contract where some spaces are left blank to be filled in later. This solves practical problems such as:
- Managing fees (which may change over time)
- Selectively controlling certain elements of the transaction
- Verifying that inputs and outputs have the same values
The Ark protocol could technically work even now, without covenants, but it would require much more interaction between users.
For optimal performance, Ark needs a system that allows for the programming of future transactions:
- CTV could be used, but it’s like using a rigid, pre-set format.
- TX_HASH would be ideal, because it offers more flexibility, like a form where some fields can be filled in later.
The difference is between needing to plan everything in detail in advance (CTV) and having a general plan with some details that can be defined as needed (TX_HASH).
LN_HANCE
LN_HANCE is a set of improvements designed specifically for the Lightning Network. It combines various technologies (OP_CHECKSIGFROMSTACK + OP_PAIRCOMMIT + OP_INTERNALKEY + OP_CTV), including CTV, to make Lightning payments more efficient and secure.
What does it enable?
- Optimized Lightning Network:
LN_HANCE makes it easier to open and manage Lightning channels. It reduces the number of transactions required to start using Lightning (currently, two transactions are needed to open a channel once your node is synchronized with the network) and makes moving funds between different channels more cost-effective. It introduces automatic systems to manage common Lightning channel issues. For example, if a channel stops functioning or a participant becomes unreachable, LN_HANCE can help recover the funds or restore the channel without manual intervention. - Intelligent Vaults:
With LN_HANCE, more sophisticated vaults can be built that can respond to different situations. For instance, a vault could automatically lock funds if it detects suspicious behavior, or it could apply different rules depending on the type of transaction being attempted. - Timeout Trees/Channel Factories:
LN_HANCE would facilitate the use of Channel Factories, a method for opening and managing channels among multiple users using a single multisig address. Participants deposit their funds into a shared on-chain address and can open, close, or manage off-chain channels without needing to return on-chain, reducing blockchain transactions and optimizing block space. Without protocol updates, Channel Factories already work, but they become difficult to manage with many participants. LN_HANCE uses solutions like OP_CTV and other technologies to simplify this complexity, enabling more efficient management and allowing some participants to act independently without involving all others. This makes them more scalable and practical for networks with many users. - Eltoo/LN-Symmetry Protocol:
Like APO, LN_HANCE also allows for the introduction of the Eltoo/LN-Symmetry protocol.
Community reactions
According to Marco Argentieri, CEO of Ark Labs, it might be easier to reach consensus on a soft fork that introduces several specialized OP_Codes that are technically simpler, rather than a soft fork that involves implementing a single, more versatile OP_Code. At Atlas21, Argentieri said:
“If the entire network supports the implementation of covenants, I believe the proposal that would gain the most consensus is The Great Script Restoration, an idea proposed by Rusty Russell that would aim to reactivate many of the OP_Codes that were deactivated in 2010 by Satoshi Nakamoto. Rushing to activate a single OP_Code now could prove to be a limiting choice in the future. I think it’s better to do a soft fork done well, rather than getting limited functionalities immediately, only to find ourselves having to perform another soft fork later.”
For Giacomo Zucco, director of Plan B Network, the best proposal would be APO, not so much for technical reasons, but rather for political ones. Speaking to Atlas21, Zucco stated:
“I think the people who proposed APO are doing an excellent and patient job of explaining their solution to try to make people understand its advantages and convince users to integrate it. On the other hand, I think OP_CAT is the victim of attempts by some players to take over Bitcoin’s governance. Currently, OP_CTV seems to be the proposal with the most support.”
According to John Carvalho, CEO of Synonym, covenants do not represent a useful solution for scaling Bitcoin and could, in fact, introduce risks to the protocol:
