13 Lines of Code to Enable Smart Contracts on Bitcoin? Understanding the OP_CAT Soft Fork
TechFlow Selected TechFlow Selected
13 Lines of Code to Enable Smart Contracts on Bitcoin? Understanding the OP_CAT Soft Fork
Bitcoin stands at a crossroads, facing a historic choice: embrace the reactivation of OP_CAT to explore smart contracts, or remain true to Satoshi's original vision of purity.
Navigating Web3 tides with focused insightsBy Jaleel, BlockBeats
An opcode long deleted by Satoshi Nakamoto and buried in history — "OP_CAT" — may be on the verge of revival within Bitcoin's codebase.
Centered around the OP_CAT opcode, the Bitcoin NFT project Taproot Wizards has launched a new NFT series called Quantum Cats, sparking heated community discussion. Although the name OP_CAT does not literally refer to cats as we know them, Taproot Wizards leveraged feline imagery to launch this new NFT collection named Quantum Cats, using meme culture to generate momentum for OP_CAT.
OP_CAT, an opcode once removed from Bitcoin’s scripting language by Satoshi Nakamoto, is now back under scrutiny. Some Bitcoin developers aim to "revive" this opcode through a 13-line soft fork, laying the groundwork for enabling smart contracts on Bitcoin. Fueled by developer advocacy and amplified by cat-themed memes, discussions around OP_CAT have reached unprecedented levels.
Reviving an Opcode Removed by Satoshi Nakamoto
Opcodes, also known as instructions or functions, are fundamental building blocks of Bitcoin's scripting language. Historically, certain opcodes were removed from early versions of Bitcoin due to concerns about potential vulnerabilities in client implementations. OP_CAT was one such opcode.
Originally part of Bitcoin’s official command set, OP_CAT allowed string concatenation—joining two elements into one. However, because serious bugs discovered in other opcodes like OP_LSHIFT could crash any Bitcoin node, and due to fears that OP_CAT might cause exponential growth of stack elements leading to memory usage scaling exponentially with script size, it was deemed risky.
As a precaution, Satoshi Nakamoto removed OP_CAT on August 15, 2010. These removed opcodes are often referred to as “disabled,” but this term is inaccurate since they were completely erased from the protocol, making them unusable by anyone on the network.
In October 2023, Bitcoin Core developer Ethan Heilman and Armin Sabouri, Chief Software Engineer at Botanix Labs, jointly published a draft Bitcoin Improvement Proposal (BIP) titled "OP_CAT," elevating the debate to a new level.
This draft contains just 13 concise lines of code yet carries clear and intuitive functionality—it defines a new tapscript opcode allowing two values on the stack to be concatenated. The implementation draws direct inspiration from the original, deleted OP_CAT.
Conditions for Revival Are Now Met
Why would developers now seek to restore an opcode deliberately removed by Satoshi? The motivation section of the BIP draft offers detailed explanation: originally, the concern centered on memory usage—OP_CAT could allow scripts where memory consumption grows exponentially relative to script size. For example, pushing a single-byte value onto the stack, duplicating it repeatedly with OP_DUP, then concatenating it 40 times via OP_CAT could inflate the stack to over 1TB in size.
However, advances in time and technology have rendered this issue obsolete. Under the tapscript architecture, a strict rule limits each stack element to no more than 520 bytes. This effectively mitigates the risk of memory explosion previously associated with OP_CAT, opening the door for its safe reintroduction.
Thus, renewed interest in reviving OP_CAT stems largely from its potential value in constructing more complex and powerful scripts. Several factors now align to support its return:
1. Demand for advanced smart contracts and protocols: As the Bitcoin ecosystem evolves, demand increases for more sophisticated smart contracts and protocols. OP_CAT enhances tapscript expressiveness by enabling object composition on the stack. It can facilitate construction and evaluation of Merkle trees and other hash-based data structures, supporting tree signatures, post-quantum Lamport signatures, non-repudiation contracts, vaults, and more.
2. Success cases on other chains: Forks like Bitcoin Cash and sidechains like Liquid have successfully re-enabled OP_CAT, using it to implement token creation and management, payment channels, and methods for embedding and retrieving data on-chain. This demonstrates that OP_CAT can be used safely and effectively under proper constraints.
3. Exploration of quantum security: Research suggests that combining operations like OP_CAT with technologies such as Lamport signatures could enable quantum-resistant Bitcoin transactions and protocols. Such exploration holds significant promise for enhancing Bitcoin’s long-term security.
4. Community and technical evolution: Ongoing development within the Bitcoin community encourages re-evaluation of past decisions. With deeper understanding of the protocol and emerging technologies, features once considered problematic may find safe and useful applications in new contexts.
Soft Forks Are Never Easy
Technically speaking, few Bitcoin proposals are as straightforward and easy to understand as OP_CAT. Yet activating OP_CAT via a soft fork—specifically by repurposing the currently unused OP_SUCCESS126 opcode—is far from simple.
The last major soft fork occurred three years ago with the activation of Taproot, which paved the way for Ordinals. Any significant change to Bitcoin undergoes rigorous community-wide discussion and review, especially when involving protocol-level changes like soft forks.
For code to be merged into Bitcoin’s repository, it must pass through a strict and transparent process ensuring both quality and broad consensus. Key steps include:
1. Writing the proposal and code: Developers first draft a comprehensive document outlining the proposal’s motivation, technical details, impact assessment, and potential risks.
2. Community discussion: After submission, members of the Bitcoin community—including developers, miners, investors, and users—review and debate the proposal. This phase is critical for assessing feasibility and gathering feedback.
3. Revisions and improvements: Based on feedback, authors may revise and refine their proposal.
4. Voting and consensus-building: For major changes affecting the protocol, broad consensus is required. Miners signal support by including specific markers in the blocks they mine.
5. Code review: Once consensus emerges, the Bitcoin Core team reviews the code for correctness and security.
6. Merging into the codebase: Upon approval, the code is integrated into Bitcoin’s official repository.
7. Deployment and activation: Network participants—miners and node operators—must upgrade their systems. Protocol changes typically require a threshold of adoption before becoming active.
Clearly, the OP_CAT soft fork remains in very early stages. Less than four months have passed since the BIP draft was published; it lacks even an official BIP number and remains in the initial phases of drafting and community discussion.
What Do Bitcoin Developers Say?
Let’s examine recent developer discussions regarding OP_CAT.
Although OP_CAT was removed, its potential utility in enabling advanced contracts and enriching Bitcoin’s scripting language has remained a recurring topic among developers. For instance, its inability to concatenate stack values has been seen as a bottleneck for certain protocols like TumbleBit, whose transaction sizes could be significantly reduced if OP_CAT were available.
After reviewing Optech newsletters and related content, here is a chronological summary of key developer commentary on OP_CAT.
2019
Ethan Heilman, one of the co-authors of the current OP_CAT BIP draft, expressed in an email in October 2019 that while he understood why OP_CAT had been removed—due to severe scripting vulnerabilities at the time—he emphasized its overlooked value: “Most protocols I want to build on Bitcoin hit a wall: inability to concatenate stack values. As a researcher, if I encounter this limitation, others likely do too. If I could wave a wand and re-enable one disabled opcode, I’d pick OP_CAT—with one condition: limit each concatenated value to 64 bytes or less.”
Andrew Poelstra is another pivotal figure in the OP_CAT discourse. On January 30, 2021, he published an article titled “CAT and Schnorr Tricks I,” reigniting widespread discussion. As Research Director at Blockstream and a seasoned Bitcoin cryptography and scripting expert, his influence is profound.
In the article, Poelstra explained: “OP_CAT enables combining two elements on the stack and pushing the result back. This allows assembling small pieces into larger ones or breaking down large items into smaller components. CHECKSIGFROMSTACK (CSFS), meanwhile, is an opcode never before implemented in Bitcoin—it allows signature verification over arbitrary data, unlike CHECKSIG, which only verifies transaction signatures.”
More importantly, he noted that combining OP_CAT with CSFS enables clever transaction introspection techniques.
Note: Transaction introspection refers to a script’s ability to inspect and analyze parts of the transaction itself. In simple terms, it allows the script to “understand” and act upon detailed information about the transaction—such as outputs, amounts, or specific signatures—enabling smarter, context-aware responses.
With this method, a user provides full transaction data on the stack; the script uses OP_CAT to pack it into a single item, hashes it, and passes it to CSFS for signature validation. Then, the same signature and public key are passed to CHECKSIG. If both validations succeed, the provided transaction data is confirmed authentic, allowing the script to perform any necessary checks based on actual transaction content.
Poelstra’s reputation and the ingenuity of this idea captured the attention of Bitcoin developers, prompting extensive discussion during that week’s development meeting about combining these opcodes and how minor script enhancements after Taproot activation could greatly improve contract flexibility.
Roughly two weeks after “CAT and Schnorr Tricks I,” Poelstra released a follow-up piece, “CAT and Schnorr Tricks II,” elaborating further on his vision.
In May 2019, Bitcoin developer Jeremy Rubin proposed the CHECKOUTPUTSHASHVERIFY opcode, aiming to implement basic, constrained smart contracts while avoiding technical and social risks inherent in earlier designs. That proposal later evolved into SECURETHEBAG, then eventually CHECKTEMPLATEVERIFY (CTV), which became BIP 0119 in January 2020.
Meanwhile, Russell O’Connor suggested directly adding CHECKSIGFROMSTACK and OP_CAT to Bitcoin to support smart contracts beyond Rubin’s limited framework. While met with opposition and fading over time—mainly due to inefficiencies in CAT+CHECKSIG-style contracts and lingering skepticism toward general-purpose smart contracts on Bitcoin—the idea planted important seeds.
Initially, Andrew Poelstra was reluctant to support Bitcoin smart contract functionality. But in autumn 2019, a private conversation with Ethan Heilman changed his perspective. Heilman pointed out that harmful smart contracts could already be implemented via CHECKMULTISIG despite lacking acceptance, and crucially, due to lack of usability and wallet support, they weren’t adopted by users. To prove this, Heilman issued a challenge on social media inviting people to propose viable “dark” smart contracts—but none succeeded.
This led Poelstra to reconsider: perhaps fear of smart contracts was overblown. His article argued that regardless of reservations, smart contracts are inevitable in Bitcoin’s evolution, and encouraged continued exploration of building them using non-specialized opcodes like OP_CAT.
2021
Next came an article by Jeremy Rubin on July 6, 2021, discussing OP_CAT from the perspective of quantum resistance. A Bitcoin developer and founder of Judica—a research org focused on Sapio, a smart contract programming language for Bitcoin—Rubin explored how OP_CAT combined with Lamport signatures could help secure Bitcoin against quantum threats.
In blog posts and mailing list messages, Rubin discussed leveraging OP_CAT and Lamport signatures to register 5-byte values via Bitcoin scripts. While elegant, this approach had limitations. He posed a question: what if we could sign longer messages? Specifically, signing up to 20 bytes would allow signing HASH160 digests—potentially quantum-safe.
Rubin further analyzed the implications of signing HASH160 digests, explaining that even if quantum computers break ECDSA, they would only reveal private keys—not invalidate existing signatures. He consulted cryptographer Madars Virza, who confirmed this insight.
Rubin concluded that requiring ECDSA signatures to themselves be signed with quantum-proof algorithms could yield quantum-resilient Bitcoin. The earlier 5-byte scheme was essentially a quantum-safe Lamport signature—but unfortunately required at least 20 contiguous bytes.
Hence, Rubin proposed needing something akin to OP_CAT. He noted OP_CAT couldn't be soft-forked directly into Segwit v0 without altering stack semantics. For simplicity, he demonstrated using a hypothetical OP_SUBSTRINGEQUALVERIFY opcode that verifies substring equality.
On November 5, 2021, at the Atlanta Bitcoin Conference, Jeremy Rubin and Andrew Poelstra presented arguments for re-enabling OP_CAT, emphasizing its importance in the Bitcoin context—particularly for quantum safety and complex smart contracts. They highlighted that combining CAT with Schnorr signature verification could theoretically enable non-recursive smart contracts capable of placing SHA2 hashes of transaction data directly onto the stack, thereby imposing granular constraints on transaction components.
They acknowledged that reintroducing CAT would add complexity but unlock new capabilities. Reviving OP_CAT requires caution to avoid past pitfalls like memory bloat.
2022
On May 18, 2022, in a Bitcoin developer mailing list thread discussing the possible reintroduction of OP_CAT, developer ZmnSCPxj suggested that achieving truly recursive smart contracts would require combining OP_CAT with proposed opcodes like OP_TX and OP_CHECKSIGFROMSTACK (CSFS). Recursive contracts rely on consensus rules ensuring all funds entering a contract can only be spent within identical future instances of that contract.
Recursive contracts depend on transaction introspection—the ability of an opcode to examine parts of the transaction executing it. Existing opcodes offer limited introspection. To enforce that previous and next outputs match, either must be dynamically constructed from constituent parts—hence the need for CAT-like functionality.
Nadav Ivgi added that even when creating recursive contracts, CAT remains essential for solving hashing challenges. This implies that output-introspection features like CTV and APO could combine with CAT to create recursive contracts. Ivgi noted that pairing these with Taproot makes writing such contract scripts easier, sharing links to two working examples.
ZmnSCPxj agreed with Ivgi’s analysis but reiterated concerns about risks of enabling recursive contracts on Bitcoin. Still, he later conceded that such contracts might be safe in practice, as they aren’t Turing-complete. Russell O’Connor referenced Poelstra’s work, noting that CAT alone, combined with existing Bitcoin features, suffices to build non-recursive contracts—and potentially recursive ones if reintroduced.
2023
In January, Anthony Towns launched Bitcoin Inquisition—a software fork of Bitcoin Core designed to run by default on signet, serving as a testing ground for soft forks and major protocol changes. By year-end 2023, it supported multiple proposals, including pull requests (PRs) for OP_CAT, OP_VAULT, and 64-byte transaction limits, signaling plans to expand the platform’s capabilities.
On August 23, 2023, Thomas Voegtlin proposed fraud proofs for expired backup states on the Lightning-Dev mailing list. He noted that adding OP_CHECKSIGFROMSTACK (CSFS) and OP_CAT via soft fork could enable on-chain use of such proofs. The idea sparked wide discussion, with Peter Todd observing the mechanism is general-purpose—not limited to LN—and potentially useful across various protocols, though he proposed simpler alternatives not discussed here.
By October, Rusty Russell conducted research on general-purpose smart contracts in modified Bitcoin scripts. Crucially, Ethan Heilman and Armin Sabouri jointly released the OP_CAT BIP draft proposing to reintroduce the concatenation opcode. Discussions on both topics continued into November.
2024
Entering 2024, Quantum Cats successfully elevated discourse around the OP_CAT BIP and Bitcoin’s developmental trajectory to a new level.
During community engagement, Bitcoin Core developer Ava Chow stated: “I don’t think CTV has rough consensus. I believe other more general smart contract proposals are closer, like txhash or CAT. That said, I haven’t closely followed the discussion.”
Ranked fifth among Bitcoin Core contributors by number of commits—with 1,292 submissions to date—and one of the few with merge rights, Ava Chow wields considerable influence in the development community.
“I’m not suggesting we activate OP_CAT. I support OP_CAT because it’s one of the few opcodes likely to achieve consensus. If you’re unfamiliar with OP_CAT, I’ve summarized the situation in this image,” said Eric Wall (@ercwl), co-founder of Taproot Wizards.
Still, Chow appears hesitant about full endorsement: “As I’ve said, I don’t believe any smart contract proposal is near rough consensus. I don’t think we should attempt to activate any of them.”
Ten Lines of Code to Enable Smart Contracts on Bitcoin
As Eric Wall (@ercwl), co-founder of Taproot Wizards, put it: “People don’t realize it, but OP_CAT is actually one of the building blocks for zk-rollups on Bitcoin.”
Reintroducing OP_CAT equips Bitcoin with a powerful tool, supporting projects like BitVM. BitVM’s recent concept—verifying arbitrary computations on Bitcoin—becomes simpler and more efficient with OP_CAT. The Bitcoin ecosystem gains capacity to build more expressive, general-purpose smart contracts.
With OP_CAT, developers can implement true smart contracts—setting predefined conditions for specific Bitcoin outputs. This opens doors for novel scaling solutions like Blockstream’s Ark, and supports many other innovation paths reliant on smart contracts. It signifies Bitcoin evolving beyond a mere payment network into a versatile, scalable computing platform.
While Wall is excited by BitVM’s underlying ideas, he views the proposal as a potential “technical dead end” for Bitcoin due to high overhead and long implementation timelines. He worries BitVM might distract the community and hinder real progress. Nevertheless, BitVM reflects ongoing innovation and exploratory spirit in blockchain and smart contract research.
Indeed, the Taproot Wizards team itself is actively working on Layer-2 solutions for Bitcoin. In a prior Space session, they revealed their $7.5 million funding round would support research into Bitcoin scaling solutions.
Thus, the OP_CAT soft fork represents a crucial milestone for them. Wall, formerly on the StarkNet Foundation board, has deep interest in building decentralized finance on permissionless settlement layers. When Ethereum emerged in 2019, he naturally gravitated toward DeFi on Ethereum.
When it became evident around 2019 that Ethereum and other blockchains could scale using zk-Rollups or optimistic fraud proofs, exploration of DeFi on Bitcoin was nearly abandoned. Driven by questions like “Can zk-Rollup scaling work on Bitcoin?” Wall shifted focus to Ethereum-based DeFi. Ultimately, however, he aims to bring those systems and technological advantages back to Bitcoin.
Additionally, in a bitcointalk forum thread discussing OP_CAT, Carter Feldman (@cmpeq), founder of the QED project, was asked how he planned to utilize this opcode in Bitcoin scripts, and whether he had calculated average witness stack byte sizes and associated fees.
Feldman acknowledged it might be somewhat expensive but explained that Merkle proofs in his project primarily serve to build trustless locking scripts or pegging systems as part of a zk-Layer-2 on Bitcoin. This system proves that given a withdrawal tree root (a public input in a zero-knowledge proof), a certain amount of Bitcoin can be withdrawn to a specific address.
To manage costs, he envisions ordinary users purchasing wrapped BTC (wBTC) on L2 by having sellers lock BTC for a period. During this time, buyers must prove they’ve paid the seller on Bitcoin L1. They know they can always redeem BTC trustlessly if needed. Meanwhile, large liquidity providers would handle actual exchanges between wBTC and BTC, charging small fees to retail users wanting to buy wBTC or bridge back to Bitcoin.
Overall, this BIP proposal for OP_CAT—requiring just 13 lines of code—could enable smart contracts on Bitcoin. However, practical implementation details will still require extensive discussion and experimentation across different projects.
Meme Culture Driving Technical Progress
Rijndael (@rot13maxi), a member of the TaprootWizards team, shared on social media the intricate mechanisms used to create their artwork. Achieving this required advanced techniques including ordinal recursion, pre-signed transactions, symmetric cryptography, and client-side load management. Notably, they chose pre-signed transactions to execute actions, demonstrating how OP_CAT or CTV-like smart contracts can pre-commit to transaction hashes.
Armin Sabouri offered a sarcastic remark: “The amount of code and technical effort invested in creating an evolving NFT collection is likely 100 times greater than what’s needed to re-enable a single opcode.”
OP_CAT is viewed as a simple, understandable opcode. Some argue it could make Bitcoin “quantum-safe” by enabling ECDSA signatures to be signed recursively. This view has gained traction and inspired Taproot Wizards’ Quantum Cats NFT campaign—to raise awareness about OP_CAT.
Yet, using meme culture to drive technical advancement isn’t unique to OP_CAT.
Inspired by Quantum Cats and its 0.1 BTC price tag—and perhaps partly fueled by criticism of its high cost—the OP_CTV community launched a meme called #rubinsreubens, a sandwich-themed promotion for OP_CTV technology.
The sandwich meme began as a humorous response to Quantum Cats and its associated memes. Ironically, it proved highly effective: much like CTV, it introduces hierarchical structure—you can layer your “sammich” as deeply as desired.
The meme attracted widespread attention. Memes are fun and can signal support, but understanding their deeper meaning matters. #rubinsreubens aims to increase awareness of op_ctv, lnhance, and new BTC opcodes and soft fork proposals enabling smart contracts.
Potential Reasons OP_CAT Could Fail
Returning to OP_CAT, there are several reasons people may oppose introducing such functionality. First, adding new opcodes like OP_CAT increases Bitcoin’s complexity, making it harder to understand and securely use, thereby increasing risk. Second, security concerns around untested features cannot be ignored—undiscovered bugs could compromise Bitcoin’s overall security. Third, soft fork upgrades that fail to achieve universal node adoption risk network splits, resulting in coexisting Bitcoin networks and complicating consensus.
New features may introduce compatibility issues, particularly if older nodes become incompatible, potentially excluding some participants from the network and harming the ecosystem. Users who don’t upgrade may find themselves unable to transact. Additionally, some may see rapid feature additions as premature, arguing urgent core protocol issues should take priority. Hasty changes risk unnecessary instability.
Beyond security and risk, two major obstacles to OP_CAT adoption are: fear of smart contracts within the Bitcoin community, and the perceived lack of “legitimacy” for Bitcoin-based smart contracts.
Fear of Smart Contracts
Apprehension toward smart contracts may represent another significant barrier to OP_CAT. While smart contracts are foundational in many blockchain ecosystems—especially platforms like Ethereum—they remain controversial in Bitcoin circles.
Bitcoiners prioritize core values like peer-to-peer exchange, decentralization, and security. Many worry that smart contracts threaten these principles. The introduction of complex logic and programmability may compromise simplicity and auditability, increasing systemic risk.
A primary concern is that smart contracts introduce complexity and security risks. Complex code increases the likelihood of bugs or exploits, which could lead to catastrophic fund losses—as seen in past incidents on other chains. Moreover, smart contracts make the system harder to audit, raising the probability of undetected flaws.
Furthermore, the Bitcoin community places immense value on stability and security. Its design philosophy favors minimalism and conservatism, prioritizing robustness over feature expansion. Thus, any change perceived as threatening network stability faces intense scrutiny and prolonged debate. While OP_CAT and smart contracts bring new possibilities, they may also be seen as diverging from Satoshi’s original vision.
Was Satoshi Wrong?
The proposal to restore OP_CAT touches a sensitive nerve: does it imply Satoshi was wrong?
Satoshi’s decisions and original design are treated almost reverently by many, with his vision seen as the guiding light for Bitcoin’s evolution. Challenging or modifying his choices may be perceived as disrespecting his legacy or deviating from Bitcoin’s foundational principles. In blockchain, legitimacy is always a central theme.
Thus, the OP_CAT revival raises a broader question: should Bitcoin remain static, or adapt to evolving technology and user needs?
Technology inevitably progresses. As an innovative system, Bitcoin cannot remain entirely immune to change. Clearly, the Taproot Wizards team believes in adaptation. After all, they intentionally created one of the largest Bitcoin blocks ever—just under the 4MB limit—to mint the Taproot Wizards NFT.
Founder Udi Wertheimer acknowledges many believe Bitcoin shouldn’t change. He agrees changes should be slow, cautious, and deliberate. But he argues Bitcoin is still too young to be frozen in place, noting governance processes are somewhat broken. While the tech community broadly agrees more upgrades lie ahead, identifying exactly which ones remains difficult. Still, Wertheimer insists change is necessary—current Bitcoin cannot serve billions.
Of course, such changes come with risks—security flaws, network splits, compatibility issues—all of which must be carefully weighed and addressed.
Looking ahead, deploying OP_CAT on test networks will be essential to ensure proposed improvements are safe and effective, allowing developers to identify and fix issues without impacting the mainnet.
Ultimately, realizing OP_CAT’s revival will take considerable time—possibly years—given the multifaceted considerations involved: technical rigor, community consensus, network security, and, critically, broad-based support and legitimacy.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
BlockBeats
