Bitcoin’s Next Major Upgrade? An Assessment of OP_CAT & OP_CTV

Executive Summary

• Bitcoin's conservative approach to protocol upgrades makes consensus changes rare, but developers remain open to optimizing its programming language and network parameters, as demonstrated by previous SegWit and Taproot upgrades.

• The programming language of Bitcoin, Bitcoin Script, inhibits transactions to carry global state and have introspection capabilities, which limits expressivity.

• Two major proposals, OP_CAT (BIP 347) and OP_CTV (BIP 119), aim to enhance Bitcoin's transaction programmability by enabling spending conditions on transaction outputs, which could significantly enhance Bitcoin Script and make it more expressive.

• The most promising use cases for OP_CAT and OP_CTV include trustless bridges between Bitcoin L1 and Bitcoin L2s, advanced self-custody vault solutions, and improvements to the Lightning Network.

• The governance process for implementing soft-fork upgrades involves multiple Bitcoin stakeholders, with media influencers and core developers currently wielding the most influence in the early stages of protocol ideation and technical review.

• Galaxy Research predicts Bitcoin Core developers will reach consensus on adding either OP_CAT or OP_CTV in 2025, though actual implementation could take 1-2 years due to the extensive activation process.

Introduction

Changes to the Bitcoin protocol require conversation and collaboration among a range of stakeholders, including but not limited to protocol developers, full nodes, end-users, and miners. Achieving consensus on protocol upgrades is laborious and often controversial. For example, the “block size wars” of 2015-2017 divided the Bitcoin community between stakeholders who wanted to alter a fundamental property of the protocol, the block size, and those who did not. The multi-year debate resulted in a permanent chain split and the creation of an alternative cryptocurrency known as Bitcoin Cash, a fork of Bitcoin.

Given the difficulty in achieving consensus on protocol changes, major upgrades to Bitcoin are rare. There is a long history of Bitcoin protocol developers rejecting contentious upgrades and taking years to implement the upgrades that do have the support of the broader Bitcoin community. This highlights developers’ commitment to preserve a conservative approach to Bitcoin development that promotes predictability, network fidelity, and backwards compatibility.

While changes to Bitcoin’s consensus are rare, Bitcoin developers have demonstrated openness to optimizing bitcoin script and network parameters. The SegWit upgrade that came from the blocksize wars did functionally increase the blocksize limit, allowing more transactions in blocks. SegWit also optimized the format of transaction data by altering the method by which transaction data is measured from bytes to virtual bytes (vbytes). The move to vbytes coupled with moving signature data to the witness field enable a Bitcoin block to include up to 4m weight units of transaction data (~4MB). The last Bitcoin soft-fork was the Taproot upgrade in 2021, which introduced an updated scripting language called Tapscript. This new version of Bitcoin Script included new signature schemes (Schnorr Signatures) that improved key aggregation to combine multiple public keys and signature into one signing key. Key aggregation with Schnorr signatures reduces the amount of data used for transactions that require multiple signatures while improving the privacy for transactions on the Lightning Network, Bitcoin’s largest P2P payment layer built on top of Bitcoin’s base layer. This high-level overview of SegWit and Taproot shows that while Bitcoin developers are hesitant to make consensus changes to Bitcoin, this does not imply that Bitcoin’s technical features are immune to change.

On the heels of SegWit and Taproot, Bitcoin developers are now exploring improving transaction programmability on Bitcoin to add additional smart contract logic to transactions. Bitcoin smart contracts involve the use of spending conditions, the ability to restrict and control how unspent transaction outputs (UTXOs) are spent in the future, with more elaborate and restrictive spending constraints known as “covenants.” This report will first provide a review on Bitcoin Script and how it functions with Bitcoin’s UTXO accounting model. Following this review, we analyze 2 pending opcodes, OP_CTV and OP_CAT, to highlight how these opcodes could potentially improve Bitcoin Script to include powerful features enabling efficient transaction programmability. Finally, the report underscores the importance of transaction programmability for bitcoin infrastructure like bridges and custody, concluding with an outlook on the consensus likelihood for OP_CAT and OP_CTV and a path to implementing these opcodes into the next soft fork upgrade.

Bitcoin Script and UTXO Model

Bitcoin uses a native scripting language to construct transactions known as “Bitcoin Script”. A script consists of a set of instructions that define how a recipient of a transaction can spend bitcoin that is being sent, also called “spending conditions.” Bitcoin Script consists of 186 opcodes, a list of script words that operate as command functions. These opcodes are used to create the official rules on how bitcoin the asset is spent and moved on the network. For example, Pay-to-PubKey Hash transactions include 4 opcodes that enforce a spending condition on a bitcoin transaction in which the bitcoin is spent to a hashed public key and can only be spent using the correct public key and private key associated with the spender.

Bitcoin script is designed for Bitcoin’s unspent transaction output (UTXO model), which uses inputs and outputs. Every Bitcoin transaction includes at least 1 input and 1 output, though most simple transactions include at least 1 input and 2 outputs (with one piece of BTC funding the transaction on the input side, with 1 piece being sent to a recipient and the remainder sent back to the spender on the output side). UTXO’s are pieces of bitcoin that have not been spent and are available to send in future transactions. UTXO’s are no longer outputs once they are used as inputs for a transaction. As a result, UTXO’s are constantly created and destroyed when users spend bitcoin. The following is a simplified example of how the UTXO model works:

1. If Alice has one UTXO worth 1 BTC in her wallet and she sends 0.5 BTC to Bob, Alice’s input will be 1 BTC.

2. Her outputs will be 0.49 BTC (going back to Alice) and 0.5 BTC (going to Bob). The 0.01 BTC delta represents the BTC paid for the transaction fee (this transaction fee will vary depending on network congestion conditions).

3. At the end of this transaction, Alice will have a new UTXO set representing the 0.49 BTC she has left.

In step 1, Alice is using her UTXO worth 1 BTC as the first input of the transaction, destroying the UTXO. In step 2, Alice creates 2 new UTXOs worth 0.5 and 0.49 BTC, one that is spent back to her as her change, and the other that is spent to Bob for payment. In step 3, Alice now has a new UTXOs worth 0.49 BTC. It should be noted that if Alice needed to pay Bob 0.5 BTC, Alice could also use multiple UTXOs that sum to 0.5 BTC in step 1; Alice now may receive back 2 new UTXOs instead of 1 if neither input UTXO is fully spent to the recipient. The UTXO model is a key feature of the Bitcoin network and plays a critical role in how transactions are processed and verified.

The UTXO example above is entirely constructed using Bitcoin script. Every UTXO contains a locking script, which includes a set of conditions for the UTXO to be spent. The locking script for the UTXO is unlocked when a user proves ownership of the input (UTXO being spent) by providing the correct private key signature associated with the corresponding public key. This information is known as a “scriptsig” and when the correct scriptsig is included in the input, the spending condition is met and the bitcoin can be spent. Going back to our UTXO example with Alice and Bob, in step 1 Alice must provide her private key signature in her input to spend her UTXO. Subsequently, Bob must provide the same information before spending his newly received 0.5 BTC.

Bitcoin’s scripting language can include more complex spending conditions such as requiring multiple signatures or unlocking bitcoin at a specific block height. However, Bitcoin script is not general purpose and lacks the same level of expressivity as other programming languages like Ethereum’s native programming language, Solidity. As a result, programming smart contract logic for bridges and custody solutions using Bitcoin script is extremely challenging.

Hurdles with Bitcoin Script as of 2025

While Bitcoin script has proven its usefulness for users and resilience against double spend attacks over the past 16 years, the scripting language lacks general purpose functions like expressivity and storing global state. Bitcoin Script is not expressive as it’s a stack-based programming language without the ability to use multiplication and arithmetic operations for large numbers. Bitcoin script can only perform non-trivial computations on values that are 32-bits large. As a result, Bitcoin Script silos stack elements larger than 32-bits from each other. This 32-bit limitation silos computationally intensive commands that use cryptographic functions, multiplication, and division, which require script sizes larger than 32 bits with the current set of opcodes. While it’s possible to emulate arithmetic and multiplication with multiple opcodes, this requires many stack elements and, unfortunately, Bitcoin Script’s stack size limit is 1000 elements. As a result, it is challenging to create complex spending conditions on transaction outputs beyond operations that exist today.

The biggest limitation of Bitcoin script is that the language cannot read/write and store transaction data as it can only read the input given by the spender. Without the ability for a programming language to store a global state, the script cannot independently verify account balances on applications or bridges. Bitcoin Script logic cannot access global state as any state data must fit in a single transaction. Consequently, it is almost impossible to develop general purpose functionality or build trustless bridges between layer 2 networks and Bitcoin’s base layer.

Initiatives to combat the limitations of Bitcoin script have been in progress since 2020. A consensus among developers has appeared to emerge over the years that the only path to make Bitcoin script more expressive is to execute a soft-fork upgrade that implements new opcodes to enable covenants. While one faction of Bitcoin views these upgrades as risks to the Bitcoin network, another faction believes that Bitcoin needs more programmability features to expand use cases for bitcoin. While no tangible progress has yet been made on which opcode suits Bitcoin the best to increase transaction programmability, advocates for covenants mostly now agree that OP_CTV and OP_CAT are the leading Bitcoin Improvement Proposals (BIPs) to enhance transaction programmability on Bitcoin. We understand that there are more than 2 solutions to implement covenants on Bitcoin, however this report will only cover OP_CTV and OP_CAT, two of the most prominent proposals.

BIP 119 (OP_CTV)

Bitcoin Improvement Proposal 119 (BIP 119), also known as CHECK-TEMPLATE-VERIFY (CTV), is a proposal created by Bitcoin core developer, Jeremy Rubin, in January 2020. The proposal introduces a new opcode, OP_CTV, which enables the implementation of general spending conditions, also called covenants, on outputs of a Bitcoin transaction. For background, the template part in “CHECK_TEMPLATE_VERIFY” refers to a transaction format that must be followed when writing Bitcoin Script. CHECK-TEMPLATE-VERIFY is a new function that enables the locking script for transaction outputs to commit to a spending condition stored within the locking script as a hash, also known as the commitment hash. As a result, the transaction output can only be unlocked if the conditions detailed in the commitment hash are met. Once broadcasted on-chain, the commitment hash associated with the transaction is immutable. The benefit of OP_CTV is the ability for the sender of a transaction to impose spending conditions on the recipient, a significant change to the current rules of Bitcoin Script that can only construct spending conditions on the sender.

There are two main types of covenants. General covenants can be replicated and applied to multiple UTXOs. The covenant does not expire after the UTXO has been spent. Pre-computed covenants on the other hand can also be replicated but only for a limited, pre-defined number of times. The logic of a pre-computed covenant must be specified by the sender in advance and differs from a general covenant in that the spending conditions cannot be replicated indefinitely. General covenants, also known as recursive covenants, may pose a risk to the fungibility of UTXOs, which is why BIP 119 advocates generally focus on use cases for OP_CTV using pre-computed covenants only, and why BIP 119 does not allow for general covenants. For example, with general covenants enabled, custodians or bitcoin exchanges could have the capability to process withdrawals that carry spending conditions that continue in perpetuity, forever encumbering those coins with the possibility of censorship by a government or other authority.

Covenants Set Up with BIP 119

Using a vault scheme as an example, here is how OP_CTV’s functionality enables covenants:

Alice wants to spend 0.8 BTC of her UTXO worth 1 BTC to both Bob and Charlie (0.4 BTC each) in 10 years. Alice also wants her change of ~0.2 BTC to be sent to a new vault that locks the BTC for an additional 10 years.

Step 1: Alice spends her UTXO worth 1 BTC to Bob and Charlie and in the locking script details that Bob and Charlie can spend the BTC in 525k blocks, approximately 10 years. Alice also includes instructions detailing that her change output worth ~0.2 BTC will be sent to a vault address she owns that will lock her UTXO for 525k blocks, approximately 10 years.

Step 2: Bob and Charlie spend their UTXOs worth 0.4 BTC each 525k blocks later. The locking script set by Alice will check the commitment hash against the current block height and, if satisfied, Bob and Charlie can spend their new UTXOs.

In step 2, after Bob and Charlie spend their UTXOs,[GP1] the part of the Bitcoin script, also called the “locking script,” that checks for the fulfillment of spending conditions will ensure that all conditions are met before releasing the BTC. This action is often referred to as “unlocking” the Bitcoin output with the correct scriptsig. If the conditions are not met, the locking script will not initiate the transfer of BTC.

Step 3: After Charlie and Bob satisfy the commitment hash in the locking script, the UTXO going back to Alice as her change (~0.2 BTC) is used as an input to an address with a specified vault scriptpubkey. The vault scriptpubkey includes a hash that allows Alice to unlock the vault after 525k blocks to spend her UTXO worth ~0.2 BTC. The benefit of using a vault scheme is that Alice can add security measures detailed in the hash like a secret recovery address to which the UTXO is spent in case someone steals her private key and attempts to unlock the UTXO before the 525k block time-lock.

Without covenants, in the previous example Alice would need to create a pre-signed transaction to enforce future spending conditions on her spent BTC to Bob and Charlie. A pre-signed transaction can either be a graph of singular or multiple transactions that are signed ahead of time by the sender’s private key, but not actually broadcast to the network for confirmation and execution. Pre-signed transactions are not scalable as they require users to store the data for multiple transactions until their execution on-chain. Additionally, pre-signed transactions require interactivity between all signing parties at the time funds can be spent. However, using commitment hashes through OP_CTV for covenants alleviates the need for users to store pre-signed transaction data and rely on interactivity between all parties associated with the transaction.

Broadly speaking, this functionality can be used to create a range of complex, highly secure, and resilient custody and security designs, helping to improve self-custody or custodial setups, create innovative new quorum or business account setups, or create more autonomous execution schemes with greater transparency and reliability.

BIP 347 (OP_CAT)

BIP 347 is another Bitcoin Improvement Proposal written by Ethan Heilman and Armin Sabouri in October 2023 that could also enable pre-computed spending conditions on outputs of a Bitcoin transaction. The proposal suggests adding the OP_CAT opcode to Bitcoin’s scripting language, a function that allows Bitcoin developers to concatenate two data points together within a stack and place these values at the top of the stack. For background, concatenating is the process of combining two or more strings of code into a single, larger string of bytes or data. Bitcoin script is a stack-based programming language that computes each string of code in sequential order. For a stack consisting of 5 lines of code, Bitcoin script will compute line 1 first and line 5 last. Unfortunately, Bitcoin’s scripting language does not include an opcode that allows developers to merge multiple strings of code throughout the entire stack. Currently, Bitcoin Script’s lack of arithmetic and multiplication capabilities inhibits the ability to compress Bitcoin script, which limits large scripts (greater than 32-bits) and small scripts (smaller than 32-bits) to interact in a single stack. Without the ability to compress script through concatenation and allow large scripts to communicate with small scripts, complex spending conditions on transaction outputs are not feasible.

Crucially, the concatenated elements of Bitcoin Script on top of the stack can emulate arithmetic and multiplication features, enabling complex scripts without the need to write long data intensive scripts that are more susceptible to bugs. Additionally, OP_CAT’s concatenation feature allows developers to generate spending conditions with Merkle Trees and other hashed data structures in Tapscript, the native scripting language used to enable new transaction types as part of the Taproot upgrade activated in November 2021.

Notably, Satoshi Nakamoto disabled OP_CAT along with other opcodes that enabled Bitcoin script to perform complex mathematical operations directly within the script. Satoshi himself removed OP_CAT because the opcode enabled the construction of data intensive scripts with the addition of OP_DUP at the time when Bitcoin’s script limit was 2000 bytes. Script sizes this large at scale could burden the computational resources of Bitcoin nodes and overload them. However, the Taproot upgrade introduced a size limit on Taproot scripts (520 bytes) in 2021, so OP_CAT can no longer introduce excessive computational overhead for node operators.

Covenants with BIP 347 (OP_CAT)

The Taproot upgrade in 2021 implemented Schnorr Signatures to Bitcoin’s scripting language. Schnorr Signatures enable public key and private key aggregation so multiple parties can collectively sign a transaction with a single signature. Combining the verification opcodes included in Schnorr Signatures with OP_CAT can create a non-recursive covenant that produces a transaction hash. Using OP_CAT, a user can constrain parts of a transaction, such as the send address or the value being sent, as a requirement of the unlocking script, with the transaction hash serving as the key to unlock it.

Using a vault scheme as an example, here is how OP_CAT’s functionality enables covenants at a high level. The highly technical aspects of this example are out of scope for this paper.

Alice wants to create a vault that unlocks her UTXO after 100 blocks:

Step 1: Alice spends her UTXO to a vault address with details of the spending conditions for the vault unlocking script including the block height into the witness field.

Step 2: During Alice’s transaction, OP_CAT concatenates the vault unlocking instructions in the witness field and hashes them twice to obtain a sighash/txhash.

Step 3: After 100 block confirmations, Alice initiates the process to spend her vaulted bitcoin by broadcasting a spend transaction for the vault UTXO. To validate that Alice has met all spending conditions, her wallet executes the CheckSig opcode in the backend. This operation performs two key validations: it verifies the transaction hash from the initial setup transaction (step 1) and compares it with the current spending transaction (step 3). The CheckSig function reconstructs the components of the setup transaction and validates the public key signature of the current transaction to ensure all vault spending conditions have been satisfied.

Step 4: After the public key for Alice’s transaction is verified by CheckSig, which re-constructs the spending conditions stored in the witness field, Alice can freely spend her UXTO.

The example above demonstrates how OP_CAT by itself cannot implement spending conditions on transactions, rather OP_CAT with the addition of other opcodes in Bitcoin Script can simplify script writing, enabling the creation of covenants. OP_CAT’s only function is to concatenate 2 elements on the top of a stack.

Although OP_CAT can be used to create covenants with CheckSig, the mere addition of only OP_CAT does not bring Solidity-like features to Bitcoin Script. This limitation is also the same for adding just OP_CTV. Even with OP_CAT, Bitcoin transactions can only perform minimal introspection, meaning that the transaction cannot fully access elements or state from previous transactions. Consequently, OP_CAT can only support granular covenants for Taproot transaction outputs. OP_CAT cannot fix leaves of a Taproot output or verify internal keys used. Taproot leaves are individual spending conditions or scripts that are committed to the Taproot output. Think of them as different "paths" or ways to spend the bitcoin - each leaf represents one possible way to spend the funds. The internal key in Bitcoin's Taproot transactions is the primary public key used for the most efficient spending path. When spending a UTXO with the internal key, you only need to provide a signature on-chain, there's no need to reveal any scripts or Merkle paths.

It should be noted that these limitations can be resolved with other opcode proposals such as OP_TWEAK_VERIFY and OP_INTERNALKEY. Overall, OP_CAT can be viewed as the main building block to generate complex spending conditions on transaction outputs, however, additional building blocks including CheckSig and others are crucial to the development of advancing Bitcoin transaction programmability.

Key Features Covenants Can Bring to Bitcoin

Trustless Bridges with Unilateral Exit

Starkware, the creators of the Starknet zk-rollup on Ethereum, published a report that highlighted how OP_CAT enables the creation of a STARK verifier and Merkle verifier to support a trustless bitcoin bridge. The trustless bridge is constructed with a recursive covenant system that maintains the bridge state through a chain of transactions recorded in a Merkle Tree. At the core of this mechanism is a persistent state of the bridge stored in an unspendable OP_RETURN output, which contains the root hash of a Merkle Tree representing account balances. The OP_CAT covenant requires each new deposit or withdrawal transaction to include a valid state transition reflecting the current bridge state. Users interact with the bridge through dedicated deposit and withdrawal covenants, which aggregate multiple transactions into batches using Merkle Trees for efficient verification. The root of this Merkle Tree is then merged into the main bridge covenant, which verifies and processes each deposit or withdrawal. During withdrawals, the covenant validates ownership by ensuring the withdrawal address matches the address of the first input in the leaf transaction. This design leverages Merkle proofs for efficient state updates within Bitcoin script, creating a trustless system where the bridge's state and rules are enforced entirely through on-chain covenant logic created with OP_CAT rather than requiring third-party trust. Crucially, for a trustless bitcoin bridge to verify state transitions for a side system, Bitcoin Script needs to verify proofs. OP_CAT’s ability to construct a STARK verifier within Bitcoin Script through concatenating hashed data together enables UTXO locking scripts to verify zk-proofs for state transitions for a side system.

The Taproot Wizard team innovated a new trustless bridge framework that combines OP_CAT with BitVM. For background, BitVM enables Turing-complete expressivity by allowing arbitrary computation to be split up and executed on Bitcoin. BitVM splits the runtime of arbitrary computation that utilizes Bitcoin Script across multiple transactions on Bitcoin. Without covenants, a BitVM bridge locking up bitcoin requires pre-signed transactions to set up the bridge. OP_CAT’s ability to carry forward data from previous transactions enables a BitVM bridge to lock and unlock bitcoin without pre-signed transactions. OP_CAT can carry forward data from previous transactions from a trick called “CAT on the stack”. This trick involves concatenating hashed data on a stack to build a Merkle Tree root, which OP_CAT can verify. As a result, a CatVM bridge ensures that specific transaction data from previous transactions, deposits, and withdrawals must be included in the next transaction to guarantee that the Merkle Root is carried over after a successful withdrawal. The CAT on stack trick also ensures that after one user withdraws their funds, the remaining bitcoin locked in the bridge can be withdrawn by any eligible user.

Advanced Vault Custody

Bitcoin vaults are a new custody solution that include security features like recovery paths, which allow users to withdraw their bitcoin to a secret address in the event of a private key leak. BIP 345, formally known as OP_VAULT, is a pending Bitcoin improvement proposal that utilizes OP_CTV to enhance security parameters for Bitcoin custody. It should be noted that OP_CAT can also be used to create spending conditions for bitcoin vaults without the need for pre-signed transactions. James O’Beirne, a Bitcoin core developer, proposed OP_VAULT in January 2023 to narrow the use cases for OP_CTV. OP_VAULT relies on OP_CTV to create the spending conditions for the vaulted bitcoin without requiring the depositor to pre-sign multiple transactions. Covenants allow the vault to have a time delay, which is triggered when anyone attempts to spend the vaulted bitcoin before the original time lock, typically this is an attacker trying to steal funds.

Non-Equivocation Contracts

Introduced in 2015, non-equivocation contracts are bitcoin transaction outputs that leak the signing key if the signer double spends. In practice, a user locks native bitcoin, which acts as a slashable bond. This bond allows the user to perform 0 confirmation transactions on the base layer that are later mined in a block. 0 confirmation transactions are instant bitcoin transactions that are validated and secured by Bitcoin’s consensus rules. If the sender of a 0 confirmation transaction spends the input before the transaction has been mined, the counterparty can slash their bitcoin bond from the leaked signing key.

Improvements to Lightning Network

OP_CAT could enable Channel Factories, which allow users to open Lightning channels without broadcasting a channel open transaction on Bitcoin’s base layer first. For example, if Alice wants to create 2 Lightning channels (one with Bob and the other with Charlie), Alice will broadcast a channel open transaction with Bob and Charlie (2 txs). A channel open transaction requires both parties to deposit bitcoin to a 2-of-2 multi-sig address. With Channel Factories, Bob and Charlie can open a separate channel with each other without having to broadcast a new channel open transaction on Bitcoin. As a result, all participants in the original channel open transactions can create independent channels with each other.

OP_CTV can create shared UTXOs, where one UTXO represents multiple users. Shared UTXOs with CTV could enable multiple users to open many Lightning Channels with one on-chain transaction. Typically, every Lightning Channel requires one on-chain transaction. As a result, if many users open Lightning Channels, this could clog up the mempool with pending transactions and increase transaction fees. While this is not a problem now, channel openings need to scale for Lightning to onboard millions of active users.

Risks Associated with OP_CAT and OP_CTV

All Bitcoin soft forks include technical risks such as bugs or unforeseen use cases for new opcodes. Although the former is rare, the latter was exposed with the creation of inscriptions. For background, inscriptions involve inputting arbitrary data in the witness field of a transaction, which has been used to create new tokens and NFT collections on Bitcoin (for more on inscriptions, read our two prior reports). The SegWit and Taproot upgrades together enabled users to input image and text data as string data into the witness field. While the creation of digital art and fungible tokens was not the focus of activating SegWit or Taproot, years later crafty developers figured out how to use these upgrades for other reasons. Galaxy Research highlighted this view in our Ordinals report and stated that the unforeseen creation of inscriptions through SegWit and Taproot could be bearish for future Bitcoin upgrades, as the community’s surprise at these new use cases may make it more hesitant to support new soft forks.

Despite the bearish sentiment about Bitcoin’s ability to upgrade, OP_CAT and OP_CTV have been heavily tested and researched. The original criticism for covenants was that governments could force applications to enforce spending conditions that only allow a set of approved addresses to spend the bitcoin. This criticism is invalid as the conditions of the spending condition are determined by the user who owns the funds. Users can create transactions that limit future spending to specific addresses, but these restrictions cannot be externally enforced by third parties, and they cannot continue in perpetuity after the locked funds have been spent. Therefore, a government has no ability to enforce how a self-custody vault application or bridge can spend funds. While custodians and bitcoin exchanges can still limit how users can spend funds, they cannot add perpetual spending conditions to withdrawn funds without the ability to perform general covenants, which OP_CTV does not allow.

Overall, OP_CAT and OP_CTV are straight forward opcodes that each do one function well. OP_CAT concatenates two elements on top of the stack, and OP_CTV can hash spending conditions within a locking script. Some use cases for these opcodes like for the development of trustless bridges still need to be researched and battle tested further as bridges can be highly susceptible to bugs and hacks.

Path to Implement Covenants to Next Soft-Fork Upgrade

Determining consensus among Bitcoin stakeholders for future protocol upgrades is a complex process that evolves over the lifetime of a proposal, also known as the BIP (Bitcoin Improvement Proposal) process. The BCAP report on Bitcoin’s history of upgrades details the role of these stakeholders as follows:

Economic nodes: Exchanges, custodians, merchants, payment providers

Investors: Whales, MicroStrategy, ETF providers, Galaxy

Media Influencers: CoinDesk, Bitcoin Magazine, X influencers, podcasts

Miners: Bitmain, MicroBT, Riot, Marathon, large private miners

Protocol Developers: Bitcoin Core developers

Application developers: Layer 2 projects

Throughout a Bitcoin Improvement Proposal's (BIP) lifecycle, different stakeholders exercise varying degrees of influence, with their relative impact shifting during the consensus-building process for implementing a soft-fork. Below is a detailed visualization of the level of power each stakeholder has ranked 1-10. OP_CAT and OP_CTV are at the protocol ideation phase as of March 2024. At this stage, media personalities have the most influence as their power can sway public opinion and create narratives. For example, Taproot Wizards is a team of high-profile Bitcoin influencers that is leveraging its large social media following to educate the Bitcoin community on the benefits of OP_CAT. The Taproot Wizards team has been producing educational content and research on OP_CAT to fuel the growing narrative that Bitcoin Script needs new opcodes to enhance transaction programmability. As a result, Taproot Wizards has cultivated an army of supporters for OP_CAT who are pushing core developers to review the OP_CAT BIP draft.

At the protocol ideation phase, Bitcoin Core developers have the second most influence as BIP editors are responsible for reviewing drafts for pending BIPs and most importantly, are the only entities that can merge the BIP into the Bitcoin Core GitHub repository[1] [GP2] . Without the support from Bitcoin Core developers, a BIP will inevitably remain shelved and eventually rejected. Bitcoin Core developers are also responsible for maintaining the Bitcoin codebase and ensuring it does not contain any bugs. Reaching consensus among Bitcoin Core developers is a difficult process as the ideological views between Core developers can differ and the influence of each Core developer in the decision-making process also varies based on their contributions and background.

Source: https://github.com/bitcoin-cap/bcap/blob/main/README.md

The OP_CAT and OP_CTV BIPs are at the stage where media influencers, users, and application developers are utilizing their influence to persuade Bitcoin Core developers that these consensus changes will improve transaction programmability on Bitcoin. The next phase of the consensus journey will require concrete research from technical influencers, application developers, and Core developers that details all potential risks of OP_CAT and OP_CTV. Without concrete research and public back and forth dialog with Core developers, the broader Core developer community will not have a collective viewpoint on OP_CAT and OP_CTV. Currently, there is a public spreadsheet that outlines the opinions of Core developers on OP_CTV and OP_CAT.

Once consensus is achieved among Core developers, OP_CAT and OP_CTV will need to be assigned a lead maintainer to facilitate the final steps before implementing the BIP into the Bitcoin Core repository. After the BIPs for OP_CAT and OP_CTV are merged into the Bitcoin Core repository, an activation method must be decided. Once an activation method is selected, the signaling period begins where Miners, investors, and economic nodes have the most influence. As of March 2024, Miners, large investors like Microstrategy, and economic nodes like Coinbase have no public view on OP_CAT and OP_CTV. These stakeholders will need further education on the risks and benefits of OP_CAT and OP_CTV prior to the BIPs being implemented.

Methods for BIP Activation

In the event Bitcoin Core developers agree on including OP_CAT or OP_CTV to the next soft fork upgrade, the community needs to agree on an activation method for the BIP. Activation methods allow miners to signal their readiness for the upgrade.

Broadly, there are two ways to execute a code change on Bitcoin. First, a code change can be executed through a soft fork. Soft forks are backwards compatible upgrades that allow Bitcoin node operators to safely operate on the Bitcoin network even if they do not upgrade their client software. Another benefit of soft forks being backwards compatible is that anyone disagreeing with the direction that Bitcoin Core (the main Bitcoin client) has the option of running older version of client software that exclude the activation of new BIPs but can still connect to the canonical Bitcoin blockchain. Soft forks add features by creating new conditions that are more limited than the existing ruleset and therefore fit inside the existing rules.

When a soft fork is activated by users, as opposed to miners, it is called a User-Activated Soft Fork (UASF). The most notable example of a UASF on Bitcoin almost occurred during the “Blocksize Wars” on August 1, 2017, to help speed up the adoption of the SegWit upgrade. During the Blocksize Wars, Bitcoin users upgraded their nodes to support the SegWit upgrade and subsequently, threatened to reject blocks from non-upgraded nodes. In doing so, miners who had not upgraded their Bitcoin client software were encouraged to adopt Segwit to have their blocks more widely propagated and increase their chances of earning block rewards. While a UASF never happened during the Blocksize wars, the threat of a potential UASF influenced miners to adopt SegWit.

The second way to implement code changes is through a hard fork, which is a backwards-incompatible upgrade that permanently splits consensus between upgrading and non-upgrading nodes. Hard forks on Bitcoin have never been implemented by core developers due to the community’s values of protocol code ossification and backwards-compatibility. Chain splits on Bitcoin can occur if a minority of users executes a hard fork upgrade such as a change to the block size. This is how Bitcoin Cash was created in 2017 when a subset of the Bitcoin community who disagreed with the Segwit upgrade and instead wanted a simple block size increase forked away from the Bitcoin protocol by activating backwards-incompatible code changes.

Beyond the difference between hard and soft fork activation, there are also differing methods for gauging community sentiment around an upgrade before a fork happens. The following is an overview of various Process-type BIPs that have been proposed by the Bitcoin community to better support the activation of soft fork upgrades:

BIP 9: BIP 9 offers a framework for miners to signal their support for a soft fork upgrade through modifications to the version bit field in a Bitcoin block header. Once the signaling period is over, the Bitcoin community can assess the percentage of miners signaling their support for an upgrade and weigh votes by miner hashrate. If a certain threshold of support is exceeded, the upgrade can then move forward with activation on a “flag day,” which is simply a specified Block Height for upgrade activation.

BIP 8: Luke Dashjr, a longtime Bitcoin core developer working on Bitcoin since 2011, proposed BIP 8 in February 2017 as the successor to BIP 9. BIP 8 proposes using Block Height instead of hashrate to determine the duration of a signaling period to approve proposals. BIP 8 also introduced a new soft fork parameter for on-chain activation known as “LOT”. If the parameter is set to “TRUE,” blocks are required to signal in the final period, ensuring the soft fork has locked in by the timeout height. From here, the upgrade activates on a predefined flag day by nodes regardless of signaling otherwise from miners. BIP 8 attempts to reduce any interference from miners delaying the activation of a proposal that the community wants and forces miners to consider the consequences of losing income due to not receiving blocks from upgraded nodes if the LOT parameter of the upgrade is set to TRUE.

Speedy Trial: A version of BIP 8 called “Speedy Trial” was introduced by Bitcoin core developers AJ Townes and Andrew Chow in April 2021. Speedy Trial attempts to accelerate the timetable for miners to signal readiness for activation. This approach activates a proposal once a majority of mined blocks within a specified period signal readiness. Speedy Trial functions like BIP 9 activation deployment with a shorter activation window. Most recently, the Taproot upgrade was activated on Bitcoin though Speedy Trial. The trial required 90% of mined blocks within a two-week period to signal readiness before Taproot could be activated on the network. The trial ended on June 12, 2021. With the threshold of 90% support from miners met, the network then transitioned into a five-month waiting period to give miners and nodes time to upgrade their software. Taproot was then officially activated on Bitcoin on November 15, 2021.

Modern Soft Fork Activation: This is an upgrade activation method that combines different properties of BIP 9 and BIP 8. It was proposed in January 2020 by Matt Corallo, one of Bitcoin Core’s most prolific contributors. This approach consists of three steps. The first step is a miner-activated soft fork outlined in BIP 9. If miners fail to activate the upgrade, the modern soft fork activation process outlined by Corallo defaults to step 2, which is a six-month period where developers and the broader Bitcoin community reconsider the code change. After the six-month period, if developers and users want to move forward with the upgrade, they can initiate step 3, which is essentially BIP 8 with the LOT parameter set to TRUE.

Conclusion

Despite OP_CAT (BIP 347) and OP_CTV (BIP 119) gaining a significant amount of support from prominent Bitcoin developers, the proposals will have to go through a lengthy due diligence process before implementation. This is because OP_CAT and OP_CTV require a change to Bitcoin’s consensus layer and the BIP governance process for such changes is extensive. Though the timeline for BIP 119 and BIP 347’s activation is not clear and remains unpredictable, the lengthy review period may benefit the proposal by giving the community ample time to educate themselves on the benefits and implications of OP_CTV and OP_CAT. Additionally, BIP contributors will have more time to stress test OP_CTV and OP_CAT along with the ramifications it may have on future bugs to Bitcoin Script.

While the full potential of OP_CAT and OP_CTV is still being explored, their most immediate impact lies in enabling trustless bridges for Bitcoin L2s and advanced secured Bitcoin vaults. The significance of trustless bridges for EVM-compatible Bitcoin L2s cannot be overstated, particularly as Bitcoin DeFi continues to evolve. These trustless solutions represent a major advancement over current alternatives like WBTC and cbBTC, which rely on trusted intermediaries and compromise the permissionless nature of blockchain technology. Although self-custodied Bitcoin vaults may offer the most practical value for custody solutions, the potential for trustless L2 bridges serves as a compelling showcase for the broader possibilities that enhanced transaction programmability can bring to Bitcoin.

The developer community's progress in advancing these proposals throughout 2024 has built significant momentum that is likely to carry forward into 2025. With Bitcoin transaction activity trending down and fee rates at 1 sat/VB, the focus is now shifting towards bringing back transaction activity on Bitcoin. While our Galaxy Research 2025 Predictions report suggests Bitcoin Core developers will reach consensus on either OP_CAT or OP_CTV, the final implementation and activation process may extend another 1-2 years. Despite this timeline, the eventual adoption of these proposals would represent a crucial milestone in the evolution of Bitcoin Script, laying the groundwork for more sophisticated and secure Bitcoin applications in the future.