What is OP_CAT?

OP_CAT is a Bitcoin opcode that Satoshi included in the original Bitcoin stack but which they removed in 2010. In October 2023, a proposal surfaced to reintroduce OP_CAT as an opcode for tapscript (the scripting language used for Taproot-enabled transactions) by redefining the existing opcode OP_SUCCESS126. 

What is OP_CAT?

To date, OP_CAT has not been assigned a BIP number. Satoshi originally removed OP_CAT because, at the time, a user could have theoretically used the opcode to push an exponential amount of data onto Bitcoin’s blockchain, resulting in a denial of service (DoS) attack. Now, however, tapscript allows a max of 520 bytes of data within a single stack (a stack is simply a data structure for Bitcoin transactions), so Bitcoin’s 2021 Taproot upgrade nullifies the original DoS vector.

OP_CAT operates by allowing a Bitcoin user to join (a.k.a. concatenate in computer science parlance) two data points together within a stack and places these values at the top of the stack, which makes these values the first items acted on in the event of a transaction. The concatenated values on the stack can ensure that the associated bitcoin can only be spent if  certain conditions are met.

To visualize what this does in practice, the tweet below, courtesy of Taproot Wizards CTO Rijndael, shows the structure of an OP_CAT transaction where 0.999 BTC can only be spent to a specific address.

OP_CAT Use Cases: Covenants

Like its counterpart, OP_CTV, OP_CAT creates spending conditions that are reinforced by tapscript and Bitcoin consensus. If enabled, it would unlock the following use cases for Taproot-enabled wallets, including:

• Vaults/Covenants: Covenants are spending conditions that allow a Bitcoin script (like tapscript) to restrict how and where an authorized user spends bitcoin; a vault is a type of covenant that creates spending conditions that requires two different transactions to appear in two separate blocks in order for a user to spend the associated bitcoin. Importantly, there are currently no methods to enforce covenants/vaults on-chain.  With OP_CAT, the concatenated values enforce certain spending conditions (as demonstrated in the tweet in the prior section) which would enable vaults and covenants. OP_CAT can also replicate CheckFromSigStack to enable simple covenants without the need for partially signed Bitcoin transactions. Covenants and vaults would improve existing cold storage and custody solutions.
• Non-equivocation contracts: Similar to the covenants and vaults described above, OP_CAT would allow for a method to penalize double spending attempts in payment channels for applications like the Lightning Network.
• Tree Signatures: As described by Ethan Heilman on the OP_CAT github: “Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.”

This list is not exhaustive, as there are other use cases for OP_CAT that are beyond the scope of this introductory article.

When and How Will OP_CAT Be Activated?

There is currently no concrete timeline for OP_CAT’s activation, as the Bitcoin developer community (and community at large) has not reached consensus on whether or not to adopt the upgrade. 

Activation discussions started circulating only months ago at the end of 2023, and discussion has ramped up significantly in 2024 as a result of the ordinal/inscription collection Quantum Cats, a quasi inscription collection and marketing campaign for OP_CAT by the Taproot Wizards team.

If the Bitcoin community did decide to activate OP_CAT, it's unclear the method by which the Bitcoin community would seek to activate it or any other upgrade. Achieving code change consensus is a loose exercise whereby Bitcoin’s most active users hash out arguments for or against certain upgrade proposals until they more-or-less agree on which one to implement next. Activating these upgrades is a whole other issue entirely, and there are multiple ways to go about it.

 Bitcoin is a decentralized system, so the safest method for upgrading it – by which we mean, the way to ensure that nothing disrupts the blockchain or splits the transaction history by introducing a newer version that is incompatible with an older version – is through what is called a “soft fork.” In Bitcoin, a soft fork is a code change that is backwards compatible, meaning that a new version of the Bitcoin software’s rules will not conflict with older versions, as opposed to a hard-fork, where the new rules are not backwards compatible and thus result in a chain split that creates a new transaction history entirely. Bitcoin’s most recent upgrades, Taproot (2021) and Segwit (2016) were both soft forks. 

Now, a soft fork provides a method for making a code change, but delivering that code change is another consensus quandary in its own right. Taproot was activated via a new method known as Speedy Trial, whereby mining pools signaled support for the upgrade by adding a signal bit within the blocks they mine; the signaling period lasted 3 months, and once 90% of blocks under a given difficulty period contained positive signals for Taproot, then the upgrade would be locked in. Speedy Trial was successful, and Taproot activated in November. 

Speedy Trial was somewhat controversial, with detractors saying that it placed too much veto power in the hands of miners to accept or reject Bitcoin upgrades. Time will tell whether the Bitcoin community opts for this method or the equally controversial user-activated soft fork in the future.