OP_CAT is a Bitcoin opcode that joins two pieces of data on the stack into one, and it is currently the subject of one of the longest-running debates in Bitcoin development. It was part of Bitcoin's original code, removed by Satoshi Nakamoto in 2010 over security concerns, and has spent the last few years as a proposed soft fork (BIP 347) that could unlock a new category of smart contract-like behavior on Bitcoin. As of July 2026, it is not active on the Bitcoin mainnet, though it is already running on a handful of Bitcoin-adjacent networks where it is quietly being stress-tested in public.
What makes OP_CAT worth understanding isn't just the code. It's the cast of characters around it: Bitcoin Core developers debating whether the change is safe, a meme-driven NFT project that raised tens of millions of dollars to lobby for its return, and a fast-growing sidechain that has already put it to work. This guide breaks down what OP_CAT does, why it was disabled, what it could enable, and exactly where things stand today.
Use the multichain Bitcoin.com Wallet app, trusted by millions to safely and easily send, receive, buy, sell, trade, use, and manage Bitcoin and crypto.
Key Takeaways
- OP_CAT (short for "operation concatenate") combines two data items on Bitcoin's stack into a single item. That's the entire function.
- It was active in Bitcoin's earliest code, then disabled by Satoshi Nakamoto in 2010 due to a denial-of-service risk.
- The proposal to bring it back, BIP 347, was authored by Ethan Heilman and Armin Sabouri and assigned its BIP number in April 2024.
- OP_CAT is not itself a covenant, but combined with other opcodes, it can be used to build covenant-like spending restrictions, including vaults.
- As of mid-2026, OP_CAT has not been activated on Bitcoin's main network. The current frontrunners for Bitcoin's next consensus soft fork are OP_CTV (BIP 119) and OP_CHECKSIGFROMSTACK (BIP 348), not OP_CAT on its own.
- OP_CAT is already live on Fractal Bitcoin, a Bitcoin-aligned sidechain, where it powers the CAT20 token standard, and it has run on the Liquid Network and Bitcoin Cash for years without a known exploit.
- A Bitcoin NFT project called Quantum Cats, created by Taproot Wizards, turned support for OP_CAT into a meme campaign that has raised more than $37 million toward OP_CAT-related development.
How OP_CAT Works
The clearest way to understand OP_CAT is to picture Bitcoin's scripting system as a small stack of building blocks. Bitcoin Script, the programming language behind every Bitcoin transaction, is a stack-based language. Data gets pushed onto the stack, opcodes act on whatever is sitting on top, and the result determines whether a transaction is valid.
OP_CAT takes the top two items on that stack and concatenates them, meaning it joins them end to end into a single combined item, which then gets placed back on top of the stack. If the stack holds the values "1" and "2," running OP_CAT removes both and replaces them with "12." According to the official specification in BIP 347, OP_CAT would push x1 || x2 onto the stack, where the double-pipe symbol denotes concatenation.
There's one important limit. OP_CAT fails if there are fewer than two values on the stack, or if joining them would create a combined value larger than 520 bytes, which is Bitcoin's maximum script element size. That byte cap matters a lot to the history of this opcode, which we'll get to shortly.
On its own, joining two strings of data doesn't sound powerful. But Bitcoin's scripting language has never had a general-purpose way to combine values on the stack, and that gap has limited what developers can build directly into Bitcoin transactions. As Bitcoin Optech explains, Bitcoin Tapscript lacks a general purpose way of combining objects on the stack, which restricts the expressiveness of Tapscript and prevents, among other things, the ability to construct and evaluate Merkle trees and other hashed data structures directly in Tapscript. OP_CAT is the proposed fix for that specific gap.
Why Was OP_CAT Disabled in 2010?
OP_CAT was part of Bitcoin's very first release. Satoshi Nakamoto removed it, along with several other opcodes such as OP_MUL, OP_DIV, and OP_OR, in 2010. The official reasoning centered on a denial-of-service risk: a script using OP_CAT repeatedly could, in theory, generate an exponentially growing piece of data, large enough to slow down or crash nodes trying to validate it.
At the time, there was no hard limit on how large a single item on Bitcoin's stack could be. That meant a malicious script could keep concatenating values until it produced a string of data heavy enough to bog down the network. Removing OP_CAT, along with the other disabled opcodes, was a conservative move that prioritized network stability over functionality the young network didn't yet need.
The landscape changed in November 2021, when Bitcoin activated the Taproot upgrade. Taproot introduced Tapscript, a new scripting context with its own rules, one of which caps any single stack item at 520 bytes. That byte limit directly closes off the original attack path. A script can still call OP_CAT, but it can never produce a value large enough to create the kind of resource-exhaustion problem that worried Satoshi in 2010. This is the technical detail that reopened the door to bringing OP_CAT back, just scoped to Tapscript rather than to all of Bitcoin Script.
Is OP_CAT a Covenant?
No, not by itself, and this is one of the most commonly misunderstood points about OP_CAT. A covenant, in Bitcoin terms, is a restriction on how an unspent transaction output (UTXO) can be spent in the future. Normal Bitcoin Script can only check whether a spend is authorized right now, typically by verifying a signature. A covenant goes further, checking not just whether a spend is authorized, but whether the resulting transaction matches a specific set of conditions.
OP_CAT does not include any built-in mechanism for inspecting transaction data. What it provides is a way to combine pieces of data on the stack, which becomes useful for covenants only when paired with other opcodes that check signatures against that combined data. BIP 347 itself states plainly that OP_CAT, while put forward for reactivation in Tapscript, is not a covenant. It is more accurate to describe it as a building block that, combined with signature-checking opcodes, can be used to emulate covenant-like behavior.
This matters because OP_CAT's flexibility is exactly what makes it both interesting and controversial. While OP_CAT may not be a covenant in and of itself, it can emulate covenants because of a quirk in how Schnorr signatures work. Combined with an opcode called CheckSigFromStack (CSFS), which checks a signature against arbitrary data rather than just the transaction itself, OP_CAT can be used to build the same kind of spending restrictions that dedicated covenant opcodes are designed to create.
What Could OP_CAT Be Used For?
Because OP_CAT is a general-purpose primitive rather than a narrowly scoped feature, developers have proposed a wide range of applications for it. The most frequently discussed include:
- Vaults. A vault is a type of covenant that requires multiple steps, often across separate transactions and blocks, before funds can move. This adds a built-in delay that gives an owner time to notice and stop unauthorized spending, improving cold storage and shared custody setups.
- Non-equivocation contracts. These can penalize a party in a payment channel, such as the Lightning Network, who tries to broadcast an outdated or fraudulent channel state, strengthening the security of off-chain payment systems.
- Tree signatures. OP_CAT enables compact multisignature scripts whose size grows only logarithmically with the number of signers, meaning a transaction under 1 kilobyte could theoretically support spend conditions across millions of public keys.
- Merkle tree construction and verification. Since building and checking a Merkle tree fundamentally requires concatenating and hashing values, OP_CAT gives Bitcoin Script the missing piece needed to do this natively.
- Post-quantum signatures. OP_CAT can enable Lamport signatures, a signature scheme considered resistant to attacks from quantum computers, since Lamport signatures require nothing more than the ability to hash and concatenate values on the stack.
- Tokenized assets and cross-chain bridges. By enabling more expressive scripts, OP_CAT could support token issuance directly on Bitcoin-aligned chains and more trust-minimized bridges between Bitcoin and other networks.
It's worth being direct about the tradeoffs here too. The same flexibility that makes OP_CAT useful for all of the above is what makes some Bitcoin developers cautious about it. Because OP_CAT is general-purpose rather than purpose-built, it opens what developers sometimes call a large design space, meaning it is harder to predict every way it might eventually be combined with other opcodes. That uncertainty is the core of the ongoing debate, not a side issue.
OP_CAT vs. OP_CTV: How the Two Leading Covenant Proposals Compare
OP_CAT is usually discussed alongside OP_CTV (OP_CheckTemplateVerify), proposed in BIP 119 by developer Jeremy Rubin. Both are aimed at giving Bitcoin some form of covenant capability, but they take almost opposite design approaches.
The practical difference comes down to scope. OP_CTV lets a transaction output commit to one exact future spending transaction, covering details like the version, locktime, outputs, and input count. Match the template, the spend goes through. Don't match, it doesn't. That narrowness is intentional. CTV is non-recursive, meaning a transaction it commits to cannot itself commit to further restrictions in a way that creates a permanent chain of constraints. Supporters consider this the safer, more contained form of covenant.
OP_CAT takes the opposite philosophy. Rather than solving one specific problem, it hands developers a flexible primitive and lets them build on top of it. Where CTV is one carefully scoped opcode designed to enable a specific set of use cases, OP_CAT is a primitive, string concatenation on the stack, that was already in the original Bitcoin scripting language before being disabled in 2010 over denial-of-service concerns that no longer apply under post-Taproot script size limits. That same flexibility is what allows OP_CAT to support recursive covenants, where one restriction can create another restriction down the line, a property OP_CTV deliberately avoids.
Is OP_CAT Live on Bitcoin Today?
Not on Bitcoin's main network. BIP 347 has reached "Complete" status as a specification document, which means the proposal itself is finished and well-defined. That is a separate thing from being deployed, which would require the broader Bitcoin community and node operators to actually activate it through a soft fork.
As of mid-2026, OP_CAT is not the leading candidate for Bitcoin's next consensus change. That position currently belongs to OP_CTV alongside OP_CHECKSIGFROMSTACK (BIP 348), a related opcode that lets a script verify a signature against arbitrary data rather than only the spending transaction itself. According to a recent Bitcoin BIP reference guide, as of mid-2026, the leading candidates for the next consensus soft fork are the covenant proposals BIP 119 (OP_CHECKTEMPLATEVERIFY) and BIP 348 (OP_CHECKSIGFROMSTACK), which would enable new scripting capabilities for vaults, channel factories, and more efficient layer-2 protocols, though no activation timeline has been set and community consensus is still forming.
OP_CTV has moved further along the activation process than OP_CAT has. Developers have published concrete signaling parameters for a BIP9-style soft fork: a signaling start date of March 30, 2026, a one-year timeout window closing March 30, 2027, a minimum activation height around May 2027, and a 90% miner signaling threshold over each two-week difficulty period. That puts CTV through the same kind of mechanism that activated Taproot in 2021, though reaching the 90% threshold is far from guaranteed given how contentious covenant proposals remain within the developer community.
None of this means OP_CAT is dead. It means the "next" soft fork conversation in 2026 is currently centered on a different pair of opcodes, and OP_CAT's path forward, if there is one, likely depends on how that CTV and CSFS debate plays out first.
OP_CAT Is Already Running Elsewhere
While OP_CAT waits on Bitcoin's mainnet, it isn't sitting untested. It has quietly been running in production on a handful of Bitcoin-related networks for years.
- Liquid Network. Blockstream's federated sidechain has had OP_CAT enabled since it launched, giving the broader Bitcoin ecosystem a real-world testbed years before BIP 347 even existed.
- Bitcoin Cash and Bitcoin SV. Both networks reintroduced OP_CAT during protocol upgrades, and it has processed transactions on these chains without a documented exploit tied to the opcode itself.
- Fractal Bitcoin. This is the most active current deployment. Fractal is a Bitcoin-aligned sidechain, built using Bitcoin Core's own software and merge-mined with Bitcoin, that launched its mainnet on September 9, 2024 with OP_CAT enabled from day one.
Fractal is worth a closer look, because it's the clearest answer to the "what would this actually look like on Bitcoin" question. Since Fractal's launch, new protocols have leveraged OP_CAT to create smart contracts based on Bitcoin software, including the CAT Protocol, which has attracted significant interest among Bitcoin-native users, along with other emerging standards that expand the network's functionality using OP_CAT.
The flagship example is CAT20, a fungible token standard built specifically to take advantage of OP_CAT. According to Fractal Bitcoin's own documentation, CAT20 is fully validated by miners and operates using smart contracts, specifically recursive covenants, enforced entirely by Bitcoin's own scripting language at the base layer, distinguishing it from token standards that rely on external or third-party validation. In practice, that means deploying, minting, and transferring a CAT20 token happens through a sequence of OP_CAT operations that build up a single string of data, which then gets inscribed directly onto the blockchain and checked by the same miners securing the network, rather than by a separate off-chain indexing service.
The Quantum Cats Story: How a Meme Campaign Pushed OP_CAT Forward
Most opcode proposals stay confined to mailing lists and GitHub threads. OP_CAT didn't, largely because of a Bitcoin Ordinals project called Taproot Wizards.
In January 2024, Taproot Wizards launched a 3,333-piece NFT-style collection called Quantum Cats, built entirely around the goal of generating public support for OP_CAT's reactivation. Quantum Cats wanted OP_CAT to create a permissionless bridge that could move bitcoin and bitcoin-based assets onto Bitcoin layer 2 chains, where they could take part in more complex trading. To even qualify for the mint, participants had to learn about the actual technical proposal and publicly advocate for its return, turning a fairly dry BIP discussion into a community campaign with real stakes attached.
The collection itself doubled as a demonstration of concatenation in action. Each Quantum Cat refers to several separate files rather than one static image, and as new files are revealed over time, the cats change, mirroring exactly what OP_CAT does by putting separate pieces of data together.
The campaign worked well enough to translate into serious funding. Taproot Wizards raised $7.5 million in 2023, followed by a $30 million round in February 2025, both explicitly earmarked for OP_CAT ecosystem development. Co-founder Udi Wertheimer described the project as focused on OP_CAT as the future of Bitcoin, with funding going toward both in-house development and supporting outside teams building on the opcode. A single Quantum Cat sale at Sotheby's, the "Genesis Cat," closed at $254,000, underscoring just how much cultural weight the campaign had picked up around a four-byte opcode.
It's a useful reminder that Bitcoin's technical debates don't always stay technical. Memes, art, and money have repeatedly become tools for pushing protocol conversations into wider view, and OP_CAT is one of the clearest recent examples of that pattern.
Conclusion
OP_CAT does one simple thing: it joins two pieces of data on Bitcoin's stack into one. What makes it significant is everything that single function could unlock, from more secure cold storage vaults to post-quantum signatures to Bitcoin-native tokens, if the Bitcoin community ever agrees to bring it back. As of July 2026, that agreement hasn't happened. BIP 347 is a finished specification sitting behind OP_CTV and OP_CHECKSIGFROMSTACK in the line for Bitcoin's next consensus soft fork, even as OP_CAT continues running quietly and without incident on Fractal Bitcoin, Liquid, and other Bitcoin-related networks. Whatever happens next, the debate around OP_CAT has already shown how a small, simple piece of code can pull in developers, artists, and investors all at once.
