The next major upgrade to Bitcoin?Evaluation of OP_CAT and OP

Author: Gabe Parker, Galaxy analyst; Translation: Bitchain Vision xiaozou

summary

Bitcoin adopts a conservative attitude towards protocol upgrades, making consensus changes rare.But as previous SegWit and Taproot upgrades show, developers are still willing to optimize Bitcoin’s programming language and network parameters.
Bitcoin programming language—Bitcoin Script, the transaction cannot carry the global state and has the ability to introspectively, which limits its expressive ability.
There are currently two main proposals,OP_CAT (BIP 347)andOP_CTV (BIP 119), They are designed to enhance the programmability of Bitcoin transactions and make transaction output more expenditure conditions.These proposals may greatly enhance Bitcoin Script’s capabilities and make it more flexible.
The most promising application scenarios of OP_CAT and OP_CTV include:Establish a trustless cross-chain bridge between the first layer (L1) and the second layer (L2) of BitcoinImprove advanced self-hosted vault solutions andImprovements to the Lightning Network.
The governance process of soft fork upgrades involves multiple Bitcoin stakeholders.Media influencers and core developers have the greatest influence in the early stages of protocol conception and technical review.
Galaxy Research predicts that Bitcoin core developers will reach a consensus on OP_CAT or OP_CTV in 2025, but due to the complex activation process, it may take 1-2 years to implement it.

1. Introduction

Changes to the Bitcoin protocol require discussion and collaboration among multiple stakeholders, including but not limited to protocol developers, full nodes, end users, and miners.The consensus process for achieving protocol upgrades is complex and controversial.For example,The “Block Size Battle” from 2015 to 2017Let the Bitcoin community be divided, one party wants to adjust the block size, the other party objectes.Years of debate ultimately led to a permanent fork of blockchain and the birth of a new cryptocurrency—Bitcoin Cash, it is a forked version of Bitcoin.

Given the difficulty of reaching an agreement to change consensus, a major upgrade to Bitcoin is rare.Bitcoin protocol developers reject controversial upgrades, and it has been a long history of time to implement those that are supported by the wider Bitcoin community.This highlights developers’ commitment to conservative attitudes towards Bitcoin development to promote predictability, network fidelity, and backward compatibility.

Although Bitcoin’s consensus changes are rare, Bitcoin developers have shown an open attitude towards Bitcoin scripts and network parameters optimization.The SegWit upgrade, born in the Block Size Battle, actually adds block size limits, allowing more transactions to be included in the block.SegWit also optimizes the format of transaction data by changing the unit of measurement of transaction data from bytes to virtual bytes.This transition, coupled with moving the signature data to the witness field, allows a Bitcoin block to contain transaction data (about 4MB) in up to 4m weight units.Bitcoin’s last soft fork is the 2021 Taproot upgrade, which introduces an updated scripting language called Tapscript.This new version of the Bitcoin script includes a new signature scheme (Schnorr signature), improves key aggregation, merging multiple public keys and signatures into one signature key.The key aggregation of Schnorr signatures reduces the amount of transaction data that requires multiple signatures, while improving the privacy of transactions on the Lightning Network (Bitcoin’s largest P2P payment layer, built on top of the Bitcoin base layer).A brief overview of SegWit and Taproot suggests that although Bitcoin developers are cautious about Bitcoin’s consensus changes, this does not mean that Bitcoin’s technical characteristics will not change.

After SegWit and Taproot, Bitcoin developers are now exploring improving transaction programmability of Bitcoin to add additional smart contract logic to the transaction.Bitcoin smart contracts involve the use of expenditure conditions, i.e. the ability to limit and control how unspend transaction outputs (UTXOs) will be spent in the future. More complex and strict expenditure constraints are called “covenants” (“restricted clauses” or “contracts”).This article will first review the Bitcoin script and how it works with Bitcoin’s UTXO accounting model.We will then analyze the two pending opcodes OP_CTV and OP_CAT to highlight how these opcodes have the potential to improve the Bitcoin script to include powerful features to enable efficient transaction programmability.Finally, this article highlights the importance of transaction programmability to Bitcoin infrastructure such as bridging and custody and looks forward to the possibility of consensus between OP_CAT and OP_CTV and the path to implementing these opcodes into the next soft fork upgrade.

2. Bitcoin Script and UTXO Model

Bitcoin uses a native scripting language to build transactions called “bitcoin scripts.”The script consists of a set of instructions that defines how the recipient of the transaction spends the bitcoin being sent, also known as the “spendence condition.”The Bitcoin script consists of 186 opcodes that run as command functions.These opcodes are used to create official rules on how Bitcoin assets are spent and transferred on the network.For example, a Pay-to-PubKey Hash transaction contains 4 opcodes that enforce expenditure conditions on Bitcoin transactions, where Bitcoin is spent to a hash public key and can only be spent using the correct public and private keys associated with the consumer.

Bitcoin scripts are designed for Bitcoin’s Unspending Transaction Output (UTXO Model) that use input and output.Each Bitcoin transaction includes at least 1 input and 1 output, although most simple transactions include at least 1 input and 2 outputs (a part of BTC at the input is used to fund transactions, part of which is sent to the receiver, and the rest is returned to the consumer at the output).UTXO is a bitcoin that has not been spent yet and can be sent in future transactions.Once UTXOs are used as inputs for transactions, they are no longer outputs.Therefore, when users spend bitcoin, UTXOs are constantly created and destroyed.Here is an example of a simplified UTXO model:

*If Alice had a UTXO worth 1 BTC in her wallet and she sent 0.5 BTC to Bob, Alice’s input would be 1 BTC.* Her output will be 0.49 BTC (returned to Alice) and 0.5 BTC (sent to Bob).The difference of 0.01 BTC represents the BTC paid to the transaction fee (this transaction fee will vary according to network congestion).*At the end of this deal, Alice will have a new UTXO set representing her remaining 0.49 BTC.In step 1, Alice destroys the UTXO using her 1 BTC worth of UTXO as the first input to the transaction.In step 2, Alice creates two new UTXOs worth 0.5 BTC and 0.49 BTC, one returned to her as her change and the other paid to Bob.In step 3, Alice now has a new UTXO worth 0.49 BTC.It should be noted that if Alice needs to pay Bob 0.5 BTC, Alice can also use multiple UTXOs in step 1, with a total of 0.5 BTC; if none of the input UTXOs are completely sent to the receiver, Alice may now receive 2 new UTXOs instead of 1.The UTXO model is a key feature of the Bitcoin network and plays a crucial role in transaction processing and verification.

The UTXO example above is built entirely using Bitcoin scripts.Each UTXO contains a lock script that includes a set of conditions that the UTXO is spent.When the user proves ownership of the input (spending UTXO) by providing the correct private key signature associated with the corresponding public key, the UTXO lock script is unlocked.This information is called “script signature”, and when the input contains the correct script signature, the expenditure conditions are met and Bitcoin can be spent.Going back to Alice and Bob’s UTXO example, in step 1, Alice must provide her private key signature in its input to spend her UTXO.Bob then had to 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 scripts are not universal and lack the expressive power of the Ethereum native programming language Solidity.Therefore, it is extremely challenging to program smart contract logic for bridging and hosting solutions using Bitcoin scripts.

3. Obstacles faced by Bitcoin scripts as of 2025

Although Bitcoin scripts have proven their utility to users and their resilience to double-spending attacks over the past 16 years, the scripting language lacks common features such as expressiveness and the ability to store global state.Bitcoin scripts are not expressive because they are a stack-based programming language that cannot multiply and arithmetic operations on large numbers.Bitcoin scripts can only perform non-trivial calculations on 32-bit size values.Therefore, the Bitcoin script isolates stack elements larger than 32 bits from each other.This 32-bit restriction isolates computationally intensive commands using encryption functions, multiplication, and division that require a larger script size than the current set of opcodes.While arithmetic and multiplication can be simulated using multiple opcodes, this requires many stack elements, while the stack size of a Bitcoin script is limited to 1000 elements.Therefore, it is challenging to create complex spending conditions on transaction output that exceeds the current operation.

The biggest limitation of Bitcoin scripts is that the language cannot read/write and store transaction data because it can only read input provided by the consumer.If the programming language cannot store the global state, the script cannot independently verify the account balance on the application or bridge.The bitcoin script logic cannot access global state because any state data must be suitable for a single transaction.Therefore, it is almost impossible to develop common functions or build trustless bridges between the L2 network and the base layer of Bitcoin.

Measures to overcome Bitcoin script restrictions have been underway since 2020.Over the years, it seems that the only way to improve the expressiveness of Bitcoin scripts is to perform soft fork upgrades, implement new opcodes to implement covenants.While some of the Bitcoin community thinks these upgrades pose a risk to the Bitcoin network, another thinks that Bitcoin needs more programmability features to scale the Bitcoin use case.Although substantial progress has not been made on which opcode is best suited to improve the programmability of Bitcoin transactions, advocates of covenants now mostly agree that OP_CTV and OP_CAT are the main Bitcoin improvement proposals (BIPs) that enhance the programmability of Bitcoin transactions.We have learned that there are more than two solutions to implement covenants on Bitcoin, but this article only describes the two most prominent proposals, OP_CTV and OP_CAT.

4. BIP 119 (OP_CTV)

Bitcoin Improvement Proposal 119 (BIP 119), also known as CHECK-TEMPLATE-VERIFY (CTV), is a proposal proposed in January 2020 by Bitcoin core developer Jeremy Rubin.The proposal introduces a new opcode OP_CTV that implements general spending conditions, i.e. covenants, on the output of Bitcoin transactions.Let’s give a simple background introduction below.The template part in “CHECK_TEMPLATE_VERIFY” refers to the transaction format that must be followed when writing Bitcoin scripts.CHECK-TEMPLATE-VERIFY is a new feature that enables the lock script output by the transaction to commit to the expenditure conditions stored in the lock script as a hash, also known as a promise hash.Therefore, the transaction output can only be unlocked if the conditions detailed in the promise hash are met.Once broadcast on-chain, the promise hash associated with the transaction is immutable.The advantage of OP_CTV is that the transaction sender can impose expenditure conditions on the receiver, which is a major change to the current rules of the Bitcoin script, and the current rules can only construct the expenditure conditions of the sender.

There are two main types of Covenants contracts.A general contract can be copied and applied to multiple UTXOs.Covenants will not expire after UTXO is spent.On the other hand, pre-calculated contracts can also be copied, but can only be used within a limited, predefined number of times.The logic of the pre-calculated contract must be specified in advance by the sender, and the difference from the general contract is that the expenditure conditions cannot be copied infinitely.General contracts, also known as recursive contracts, may pose risks to UTXO’s substitutability, which is why BIP 119 advocates usually focus only on OP_CTV use cases that use pre-computed contracts, and why BIP 119 does not support general contracts.For example, if a general contract is enabled, the custodian or Bitcoin exchange may be able to handle withdrawals with permanent spending conditions, which may never get rid of the possibility of being scrutinized by the government or other authority.

5. Deploy Covenants using BIP 119

Taking the vault plan as an example, the following is about how the OP_CTV function implements covenants:

Alice hopes to spend 0.8 BTC of her 1 BTC UTXO to Bob and Charlie (0.4 BTC per person) over the next 10 years.Alice also hopes to send her change of about 0.2 BTC to a new vault that locks BTC for another 10 years.

Step 1:Alice spent her 1 BTC UTXO to Bob and Charlie, and detailed in the lock script that Bob and Charlie can spend BTC after 525k blocks, which is about 10 years later.Alice also includes instructions detailing her change output of about 0.2 BTC will be sent to the vault address she owns, which will lock her UTXO 525k blocks, i.e. about 10 years later.

Step 2:Bob and Charlie spent their respective UTXO worth 0.4 BTC after 525k blocks.The lock script set by Alice will check the promise hash based on the current block height, and Bob and Charlie can spend their new UTXO if the criteria are met.

In step 2, after Bob and Charlie spend their UTXO, part of the Bitcoin script, also known as the “lock script”, will check the fulfillment of the expenditure conditions, ensuring that all conditions are met before BTC is released.This operation is often called “unlocking” the bitcoin output with the correct script signature.If the condition is not met, the lock script will not initiate the transfer of BTC.

Step 3:After Charlie and Bob satisfy the promise hash in the lock script, the UTXO returned to Alice as change (approximately 0.2 BTC) is used as input to have the address of the specified vault script public key.The vault script public key includes a hash that allows Alice to unlock the vault after 525k blocks to spend her UTXO worth about 0.2 BTC.The benefit of using the vault scheme is that Alice can add detailed security measures in the hash, such as a secret recovery address, in case someone steals her private key and tries to unlock the UTXO before the 525k block time lock.

Without covenants, in the previous example, Alice needs to create a pre-signed transaction to enforce future spending conditions on the BTC she spent on Bob and Charlie.A pre-signed transaction can be a single or multiple transactions, signed in advance by the sender’s private key, but is not actually broadcast to the network for confirmation and execution.Pre-signed transactions are not scalable because they require users to store data for multiple transactions until they are executed on the chain.Additionally, pre-signature transactions require interaction between all signatory parties when funds can be spent.However, implementing covenants using promise hash through OP_CTV reduces the need for users to store pre-signed transaction data and rely on interaction between all parties associated with the transaction.

Broadly speaking, this feature can be used to create a complex, highly secure and resilient hosting and secure design that helps improve self-hosting or hosting settings, create innovative new quorums or business account settings, or create more autonomous execution solutions with greater transparency and reliability.

6. BIP 347 (OP_CAT)

BIP 347 is another Bitcoin improvement proposal written by Ethan Heilman and Armin Sabouri in October 2023, which can also implement pre-calculated spending conditions on the output of Bitcoin transactions.The proposal suggests adding the OP_CAT opcode to Bitcoin’s scripting language, a feature that allows Bitcoin developers to “connect” two data points together in the stack and place these values on the top of the stack.Let’s take a look at a brief background introduction.Concatenating is the process of combining two or more code strings into a larger byte or data string.Bitcoin scripts are stack-based programming languages that calculate each code string in order.For a stack consisting of 5 lines of code, the Bitcoin script will first calculate line 1 and finally calculate line 5.Unfortunately, Bitcoin’s scripting language does not contain opcodes that allow developers to merge multiple code strings throughout the stack.Currently, Bitcoin scripts lack arithmetic and multiplication capabilities, suppressing the ability to compress Bitcoin scripts, which limits the interaction of large scripts (greater than 32 bits) and small scripts (greater than 32 bits) in a single stack.Complex spending conditions on transaction output are not feasible without the ability to compress scripts through “connection” and allow large scripts to communicate with small scripts.

Crucially, the concatenated elements of the bitcoin script at the top of the stack can simulate arithmetic and multiplication functions, enabling complex scripts without the need to write longer, data-intensive scripts that are more error-prone.Additionally, OP_CAT’s connectivity feature allows developers to generate spending conditions using Merkle tree and other hash data structures in Tapscript, a native scripting language used to enable new transaction types as part of the Taproot upgrade activated in November 2021.

It is worth noting that Satoshi Nakamoto disables OP_CAT and other opcodes that enable Bitcoin scripts to perform complex mathematical operations directly within the script.Satoshi Nakamoto himself deleted OP_CAT because the opcode was limited to 2000 bytes when the bitcoin script was limited to OP_DUP, data-intensive scripts could be built in combination with OP_DUP.Scripts of this scale may increase the computing resource burden on Bitcoin nodes and overload them.However, the Taproot upgrade introduced a size limit (520 bytes) for Taproot scripts in 2021, so OP_CAT no longer introduces excessive computational overhead for node operators.

7. Deploy Covenants using BIP 347 (OP_CAT)

The 2021 Taproot upgrade introduces Schnorr signatures into the Bitcoin scripting language.Schnorr signature supports public and private key aggregation, allowing multiple parties to sign a transaction together through a single signature.Combining the verification opcode contained in the Schnorr signature with OP_CAT can create a non-recursive contract that generates a transaction hash.Through OP_CAT, users can constrain certain parts of a transaction, such as sending address or sending amount, as a requirement for the unlocking script, and the transaction hash serves as the key to unlocking.

Taking the vault scheme as an example, the following is an overall overview of how the OP_CAT function implements Covenants.The technical details of this example are beyond the scope of this article.

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

*Step 1:Alice spends its UTXO to a vault address and contains details of the spending condition of the vault unlock script in the witness field, including block height.

*Step 2:During Alice’s transaction, OP_CAT connects the vault unlock instructions in the witness field and hash them twice to get the sighash/txhash.

*Step 3:After 100 blocks are confirmed, Alice initiates the process of spending his vault bitcoin by broadcasting UTXO’s spending transactions.To verify that Alice meets all expense conditions, her wallet executes the CheckSig opcode in the background.This operation performs two key validations: Verify that the transaction hash in the initial setup transaction (step 1) and compare it with the current spending transaction (step 3).The CheckSig function rebuilds the components that set up the transaction and verifies the public key signature of the current transaction to ensure that all vault expenditure conditions are met.

*Step 4:After the public key of the Alice transaction is verified by CheckSig (CheckSig reconstructs the spending conditions stored in the witness field), Alice is free to spend her UTXO.

The above example shows that OP_CAT itself cannot implement expenditure conditions on transactions, but that OP_CAT combined with other opcodes in Bitcoin scripts can simplify scripting and thus implement covenants.The only function of OP_CAT is to connect two elements at the top of the stack.

Although OP_CAT can be used together with CheckSig to create covenants, adding OP_CAT alone does not bring Solidity-like functionality to Bitcoin scripts.This limitation also applies to adding OP_CTV only.Even with OP_CAT, Bitcoin transactions can only perform minimal introspection, meaning that transactions cannot fully access the elements or states of previous transactions.Therefore, OP_CAT can only support fine-grained covenants of Taproot transaction output.OP_CAT cannot fix leaf nodes output by Taproot or verify internal keys used.A Taproot leaf node is a single spending condition or script submitted to the Taproot output.They can be considered as different “paths” or ways to spend Bitcoin—each leaf node represents a possible way to spend.The internal key in a Bitcoin Taproot transaction is the primary public key used for the most efficient spending path.When spending UTXO with an internal key, you just need to provide the signature on the chain without revealing any scripts or Merkle paths.

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

8. Key features that Covenants can bring to Bitcoin

(1) Trustless bridge and unilateral exit

Starkware (creator of Starknet zk-rollup on Ethereum) released a report highlighting how OP_CAT supports the creation of STARK validators and Merkle validators for trustless Bitcoin bridging.Trustless bridging is built with a recursive contract system that maintains the bridging state by recording a chain of transactions in the Merkle tree.The core of this mechanism is the bridge persistence state stored in the non-spending OP_RETURN output, which contains the root hash of the Merkle tree representing the account balance.OP_CAT covenant requires that each new deposit or withdrawal transaction contains a valid state transition that reflects the current bridged state.Users interact with bridges through dedicated deposit and withdrawal covenants that use Merkle tree to aggregate multiple transactions into batches for efficient verification.The roots of the Merkle tree are then merged into the main bridge contract, which verifies and processes each deposit or withdrawal.During withdrawal, the deed verifies ownership by ensuring that the withdrawal address matches the address entered in the first input in the leaf transaction.The design utilizes Merkle proof for efficient state updates in bitcoin scripts to create a trustless system where the state and rules of the bridge are enforced entirely through on-chain contract logic created by OP_CAT without the need for third-party trust.Crucially, for trustless Bitcoin bridging of system state transitions on the verification side, the Bitcoin script needs verification proof.OP_CAT enables the UTXO lock script to verify the zk-proof (zero knowledge proof) of system state transitions by connecting hash data together.

The Taproot Wizard team has innovated a new trustless bridging framework that combines OP_CAT with BitVM.BitVM achieves Turing’s complete expression capabilities by allowing segmentation and execution of arbitrary computing on Bitcoin.BitVM splits the runtime of arbitrary computations into multiple transactions on Bitcoin using the runtime of arbitrary computing of the Bitcoin script.Without covenants, BitVM bridges that lock Bitcoin require pre-signed transactions to set up the bridge.OP_CAT’s ability to carry data from previous transactions enables BitVM bridge to lock and unlock Bitcoin without pre-signed transactions.OP_CAT can carry data from previous transactions through a technique called “CAT on the stack”.This trick involves concatenating hashed data on the stack to build a Merkle tree root, which OP_CAT can verify.Therefore, CatVM bridge ensures that specific transaction data from previous transactions, deposits and withdrawals must be included in the next transaction to ensure that the Merkle root is continued after a successful withdrawal.The CAT on the stack tips also ensure that after one user withdraws, the remaining bridged bitcoins can be withdrawn by any eligible user.

(2) Advanced Vault Trust

Bitcoin Vault is a new custody solution that includes security features such as recovery paths that allow users to withdraw their Bitcoins to a secret address in the event of private key leaks.BIP 345, officially named OP_VAULT, is a pending Bitcoin improvement proposal that uses OP_CTV to enhance the security parameters of Bitcoin custody.It should be noted that OP_CAT can also be used to create a Bitcoin vault for expenditure conditions without pre-signature transactions.Bitcoin core developer James O’Beirne proposed OP_VAULT in January 2023 to narrow the scope of OP_CTV’s use cases.OP_VAULT relies on OP_CTV to create spending conditions for vault bitcoin without the depositor signing multiple transactions in advance.Covenants allow vaults to have time delays, and when anyone tries to spend vault bitcoins before the original time lock, the time delay will be triggered, usually this is an attacker trying to steal funds.

(3) Non-Equivocation contract

The Non-Equivocation contract was introduced into the Bitcoin network in 2015 and is the output of Bitcoin transactions. If the signer spends double, the signature key will be leaked.In practice, users lock in native Bitcoin as a deposit that can be confiscated.This margin allows the user to execute 0 confirmation transactions on the base layer, which are later dug up in the block.0 Confirmation transactions are instant Bitcoin transactions verified and protected by Bitcoin consensus rules.If the sender of the 0 confirms that the transaction spends input before the transaction is mined, the counterparty can confiscate its Bitcoin margin from the leaked signature key.

(4) Improvement of Lightning Network

OP_CAT can enable Channel Factory, allowing users to open a lightning channel without first opening transactions on the BTC base layer.For example, if Alice wants to create 2 lightning channels (one with Bob and the other with Charlie), Alice will broadcast the channel open transactions with Bob and Charlie (2 transactions).The channel opening transaction requires both parties to deposit Bitcoin into 2/2 of the multi-signature address.Through the channel factory, Bob and Charlie can open separate channels to each other without broadcasting new channels to open transactions.Therefore, all participants in the original channel open transaction can create independent channels from each other.

OP_CTV can create shared UTXOs, where one UTXO represents multiple users.Shared UTXO using CTV allows multiple users to open multiple lightning channels through an on-chain transaction.Typically, each lightning channel requires an on-chain transaction.Therefore, if many users turn on the lightning channel, this may fill the memory pool with pending transactions and increase transaction fees.While this is not a problem at the moment, the channel opening needs to be expanded to support the Lightning Network to attract millions of active users.

9. Risks related to OP_CAT and OP_CTV

All Bitcoin soft forks contain technical risks, such as errors in new opcodes or unforeseen use cases.Although the former is rare, the latter is exposed in the creation of inscriptions.The inscription involves entering arbitrary data in the witness field of the transaction, which has been used to create new tokens and NFT collections on Bitcoin.SegWit and Taproot upgrades jointly enable users to enter image and text data as string data into the witness field.While digital art and the creation of alternative tokens are not the focus of activating SegWit or Taproot, years later, smart developers have discovered how these upgrades can be used for other purposes.Galaxy Research highlighted this point in our Ordinals report, noting that the inscriptions created unexpectedly through SegWit and Taproot could have a negative impact on future Bitcoin upgrades, as the community’s surprise at these new use cases could make it even more hesitant to support new soft forks.

Despite the existence of bearish sentiment on Bitcoin’s ability to upgrade, OP_CAT and OP_CTV have been tested and studied extensively.The initial criticism of covenants was that the government might force applications to enforce spending conditions that would allow only one set of approved addresses to spend Bitcoin.This criticism is invalid because the conditions for expenditure are determined by the users who own the funds.Users can create transactions that limit future spending to a specific address, but these restrictions cannot be enforced externally by third parties and cannot be permanently extended after locked funds are spent.Therefore, the government cannot enforce self-custodial vault apps or how bridge spends money.While custodians and Bitcoin exchanges can still limit how users spend money, they cannot add permanent spending conditions to withdraw funds without the ability to execute the general contract, and OP_CTV does not allow general contracts.

Overall, OP_CAT and OP_CTV are simple opcodes, each performing a function well.OP_CAT joins two elements at the top of the stack, while OP_CTV can hash the spending conditions in the lock script.Some use cases of these opcodes (such as development of trustless bridging) still require further research and practical testing, as bridges are extremely vulnerable to bugs and hacking attacks.

10. The next soft fork upgrade Covenants deployment path

Determining Bitcoin stakeholders’ consensus on future protocol upgrades is a complex process that evolves with the life cycle of the proposal—also known as the BIP (Bitcoin Improvement Proposal) process.The BCAP report on Bitcoin upgrade history describes the roles of these stakeholders in detail as follows:

*Economic node:Exchanges, custodians, merchants, payment providers

*investor:Giant Whale, MicroStrategy, ETF Provider, Galaxy

*Media celebrity:CoinDesk, Bitcoin Magazine, X Celebrities, Podcasts

*Minder:Bitmain, MicroBT, Riot, Marathon, large private miners

*Protocol developer:Bitcoin Core Developer

*Application developer:L2 Project

Throughout the life cycle of the Bitcoin Improvement Proposal (BIP), different stakeholders exercise varying degrees of influence, and their relative influence changes during the implementation of the consensus building of soft forks.The following are detailed divisions of each stakeholder influence level, ranking by 1-10.As of March 2024, OP_CAT and OP_CTV are in the protocol conception stage.Media figures are at the most influential stage because they can influence public opinion and create narratives.For example, Taproot Wizards is a team of well-known Bitcoin celebrities who use their huge social media fan base to promote the benefits of OP_CAT to the Bitcoin community.The Taproot Wizards team has been producing educational content and research on OP_CAT to drive a narrative where bitcoin scripts require new opcodes to enhance transaction programmability.As a result, Taproot Wizards has developed a large number of supporters for OP_CAT, who are pushing core developers to review the OP_CAT BIP draft.

During the protocol conception phase, Bitcoin core developers ranked second in influence because BIP editors were responsible for reviewing the draft of the pending BIP and, most importantly, they were the only entities that could merge BIPs into the Bitcoin core GitHub repository.Without the support of Bitcoin core developers, BIP will inevitably be put on hold and eventually rejected.Bitcoin Core developers are also responsible for maintaining the Bitcoin code base and ensuring that it does not contain any errors.A consensus among Bitcoin core developers is a difficult process, as ideological perspectives may vary among core developers, and the influence of each core developer in the decision-making process varies by contribution and context.

OP_CAT and OP_CTV BIP is at the stage where media celebrities, users and application developers use their influence to convince Bitcoin core developers that these consensus changes will improve the programmability of Bitcoin transactions.The next phase of the consensus journey will require specific research by tech celebrities, application developers and core developers, detailing all the potential risks of OP_CAT and OP_CTV.Without specific research and open dialogue with core developers, there will be no broader core developer community that has formed a collective view of OP_CAT and OP_CTV.

Once a consensus is reached among core developers, OP_CAT and OP_CTV will need to designate a primary maintainer to facilitate the final step of implementing BIP to the Bitcoin core repository.After the BIP of OP_CAT and OP_CTV is merged into the Bitcoin core repository, it is necessary to decide on the activation method.Once the activation method is selected, the signal period begins, and miners, investors and economic nodes have the greatest influence.As of March 2024, large investors such as miners, Microstrategy, and economic nodes such as Coinbase have not yet expressed public opinions on OP_CAT and OP_CTV.Before BIP implementation, these stakeholders need to understand more about the risks and benefits of OP_CAT and OP_CTV.

11. BIP activation method

If Bitcoin Core developers agree to include OP_CAT or OP_CTV in the next soft fork upgrade, the community needs to agree on how to activate BIP.The activation method allows miners to signal their preparation for the upgrade.

Broadly speaking, there are two ways to perform code changes on Bitcoin.First, you canSoft forkPerform code changes.Soft forks are backward compatible upgrades that allow bitcoin node operators to run safely on the Bitcoin network even without upgrading their client software.Another benefit of backward compatibility of soft forks is that anyone who disagrees with the direction of Bitcoin Core (the main Bitcoin client) can choose to run an older version of client software that excludes new BIP activations, but can still connect to the canonical Bitcoin blockchain.Soft forks add functionality by creating new conditions that are more limited than existing rulesets, so fits in existing rules.

When a soft fork is activated by a user (not a miner), it is called a user-activated soft fork (UASF).The most famous UASF example on Bitcoin happened almost during the “block size battle” on August 1, 2017 to help speed up adoption of the SegWit upgrade.During the block size battle, Bitcoin users upgraded their nodes to support SegWit upgrades and subsequently threatened to reject blocks from unescalated nodes.By doing so, miners who have not upgraded their Bitcoin client software are encouraged to adopt Segwit to make their blocks spread more widely and increase their chances of receiving block rewards.Although UASF never occurred during the block size war, the threat of potential UASF affected miners’ adoption of SegWit.

The second way to implement code changes is throughHard fork, This is a backward incompatible upgrade that will permanently split the consensus between upgraded and unupgraded nodes.Bitcoin core developers have never implemented a hard fork because the community values the solidification and backward compatibility of protocol code.If a small number of users perform hard fork upgrades (such as changing the block size), a chain split may occur in Bitcoin.This is how Bitcoin Cash was created in 2017, when some of the Bitcoin community disagreed with the Segwit upgrade, hoping to simply increase the block size by activating backward incompatible code changes to fork out of the Bitcoin protocol.

In addition to the difference between hard fork and soft fork activation, there are different ways to measure community sentiment about escalation before the fork occurs.Here is an overview of various process types BIPs proposed by the Bitcoin community to better support activation of soft fork upgrades:

*BIP 9:BIP 9 provides a framework for miners to signal their support for soft fork upgrades by modifying the version bitfield in the Bitcoin block header.Once the signal period is over, the Bitcoin community can evaluate the percentage of miners supporting upgrades and vote weighted by miner computing power.If a certain support threshold is exceeded, the upgrade can continue to be activated on “flag day”, which is only a specified block height for upgrade activation.

*BIP 8:Long-term Bitcoin core developer Luke Dashjr (who has been working in Bitcoin development since 2011) proposed BIP 8 as the successor to BIP 9 in February 2017.BIP 8 recommends using block height rather than computing power to determine the duration of the signal period for an approval proposal.BIP 8 also introduces a new on-chain activation soft fork parameter called “LOT”.If this parameter is set to “TRUE”, a signal needs to be issued during the final period to ensure that the soft fork is locked at the timeout height.From here, upgrades in predefined flag days are activated by nodes regardless of whether the miner signals or not.BIP 8 attempts to reduce the interference of miners on the community’s desired proposal activation and forces miners to consider the consequences of lost revenue due to not receiving blocks from upgraded nodes with the upgraded LOT parameter set to TRUE.

*Speedy Trial:Bitcoin core developers AJ Townes and Andrew Chow introduced a version of BIP 8 called the Speedy Trial in April 2021.Speedy Trial attempts to speed up the miner’s schedule to issue activation preparation signals.This approach means that the proposal will be activated once the majority of the mining blocks send a prepared signal within a specified period.Speedy Trial features similar to BIP 9 activation deployments, but with a shorter activation window.Recently, the Taproot upgrade has been activated on Bitcoin via Speedy Trial.The trial requires 90% of the mining blocks to send a prepared signal within two weeks before Taproot can be activated on the network.The trial ended on June 12, 2021.After reaching the threshold of 90% miner support, the network then enters a five-month wait period to leave 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 a method of upgrading activation that combines different attributes of BIP 9 and BIP 8.It was proposed in January 2020 by Matt Corallo, one of Bitcoin Core’s most prolific contributors.The method includes three steps.The first step is the miner activation soft fork outlined in BIP 9.If miners fail to activate the upgrade, the modern soft fork activation process outlined by Corallo will default to the second step, the six-month waiting period for developers and the broader Bitcoin community to reconsider code changes.Six months later, if developers and users wish to continue upgrading, they can start step 3, which is essentially equivalent to BIP 8 with the LOT parameter set to TRUE.

12. Conclusion

Although OP_CAT (BIP 347) and OP_CTV (BIP 119) have received support from many well-known Bitcoin developers, these proposals still require a long due diligence process before implementation.This is because OP_CAT and OP_CTV require changes to Bitcoin’s consensus layer, and the BIP governance process for such changes is very extensive.Although the activation schedule for BIP 119 and BIP 347 is unclear and unpredictable, the long review period may benefit the proposal as it provides the community with plenty of time to understand the benefits and impacts of OP_CTV and OP_CAT.Additionally, BIP contributors will have more time to stress test OP_CTV and OP_CAT, as well as their potential impact on future bugs in Bitcoin scripts.

Although the full potential of OP_CAT and OP_CTV is still being explored, their most direct impact is the implementation of trustless bridging and advanced security bitcoin vaults for Bitcoin L2.The importance of trustless bridging for EVM-compatible Bitcoin L2 is self-evident, especially in the context of Bitcoin DeFi’s growing environment.These trustless solutions represent significant advances over current alternatives such as WBTC and cbBTC, which relies on trusted intermediaries and weaken the permissionless nature of blockchain technology.While self-custodial Bitcoin vaults may offer the most practical value in custody solutions, the potential of trustless L2 bridges demonstrates the wider possibilities that enhanced transaction programmability brings to Bitcoin.

The developer community has made significant progress in promoting these proposals in 2024, and this good momentum may continue into 2025.As Bitcoin trading activity tends to decline and transaction fees as low as 1 sat/VB, the current focus is shifting to how to restore transaction activity on the Bitcoin network.Although our Galaxy Research 2025 forecast report believes that Bitcoin core developers will reach a consensus between OP_CAT or OP_CTV, the final implementation and activation process may take 1-2 years.Nevertheless, the final adoption of these proposals will be an important milestone in the evolution of Bitcoin scripts, laying the foundation for more complex and secure Bitcoin applications in the future.

By enhancing transaction programmability, Bitcoin will be able to support more innovative use cases such as trustless cross-chain bridging and advanced custody solutions, further driving the Bitcoin ecosystem.The introduction of these technologies will not only enhance the functionality of Bitcoin, but will also provide developers and users with more tools to build safer and more efficient decentralized applications.While achieving these goals requires time and community efforts, its potential impact will undoubtedly inject new vitality into the future of Bitcoin.