OP_CAT (Proposed)

What Is OP_CAT?

OP_CAT is a Bitcoin Script opcode that takes the top two values from the stack, concatenates them into a single byte string, and pushes the result back. For example, given stack values 0xB10C and 0xCAFE, OP_CAT produces 0xB10CCAFE. Its opcode number is 0x7e (126 in decimal).

BIP-347, authored by Ethan Heilman and Armin Sabouri, proposes re-enabling OP_CAT within Tapscript (the scripting language introduced by the Taproot soft fork). The proposal redefines the currently unused opcode OP_SUCCESS126 to function as OP_CAT, requiring a soft fork to activate on mainnet.

While concatenation sounds trivial, OP_CAT is one of the most discussed Bitcoin upgrades because it provides a building block for transaction introspection: the ability for a script to inspect and enforce conditions on the transaction spending it. This single capability opens the door to covenants, smart contracts, and programmable Bitcoin that were previously impossible without more invasive protocol changes.

How It Works

At the implementation level, OP_CAT is straightforward. It pops two elements from the stack, appends the second to the first, checks that the result does not exceed 520 bytes, and pushes the concatenated value back onto the stack.

// Simplified pseudocode from BIP-347
case OP_CAT:
  if (stack.size() < 2)
    return SCRIPT_ERR_INVALID_STACK_OPERATION;

  vch1 = stacktop(-2);  // second from top
  vch2 = stacktop(-1);  // top of stack

  if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
    return SCRIPT_ERR_PUSH_SIZE;  // 520-byte limit

  vch1.append(vch2);    // concatenate
  stack.pop_back();     // remove top, result is in vch1

The operation fails if the stack has fewer than two elements or if the resulting byte string exceeds the 520-byte maximum stack element size enforced in Tapscript.

Historical Context

OP_CAT was present in Bitcoin from the very first release. In 2010, Satoshi Nakamoto disabled it along with 15 other opcodes in a commit labeled simply "misc changes." The concern was a denial-of-service vector: without a size limit, a script could use OP_DUP and OP_CAT in a loop to double the size of a stack element with each iteration, creating a value exceeding one terabyte after only 40 repetitions.

Satoshi actually introduced a stack element size limit (initially 5,000 bytes, then reduced to 520 bytes) in the same period, but still chose to disable the opcode entirely. The 520-byte limit has remained in place ever since and was carried forward into Tapscript by BIP-342. With this limit enforced, the original attack is completely neutralized: OP_CAT can never produce an element larger than 520 bytes, no matter how many times it executes.

The Schnorr Trick: Why Concatenation Enables Introspection

The reason a simple concatenation opcode unlocks so much functionality lies in the structure of Schnorr signatures. A Schnorr signature is computed over a hash of three values concatenated together: the public key's x-coordinate, the nonce's x-coordinate, and the transaction data (the sighash).

With OP_CAT, a script can reconstruct this hash from its component parts inside Script itself. The spender provides the transaction data as a witness element, and the script uses OP_CAT to assemble the expected signature hash, then verifies it with OP_CHECKSIG. If the signature passes, the script knows the provided transaction data is authentic, because only the correct data would produce a valid signature.

This technique, described by Andrew Poelstra in his 2021 "CAT and Schnorr Tricks" paper, effectively gives Bitcoin Script the ability to see the transaction that is spending it. From there, the script can enforce arbitrary conditions: restricting which addresses can receive the funds, requiring specific output amounts, or mandating that the spending transaction recreate certain script conditions in its outputs.

Use Cases

Covenants and Vaults

Covenants are spending restrictions that persist across transactions. A covenant can enforce rules like "these funds can only be sent to address X" or "withdrawals require a 24-hour delay." OP_CAT enables covenant emulation through the Schnorr introspection trick, allowing scripts to constrain which outputs a spending transaction must create.

Vaults are a practical application of covenants: a vault script enforces a mandatory time delay before funds can be moved to an external address. During the delay, a timelock-protected recovery path allows the owner to claw back funds if their keys are compromised. This provides a security layer beyond traditional self-custody models. For a deeper exploration of covenant mechanics, see the Bitcoin covenants explainer.

Validity Rollups and Trustless Bridges

One of the most ambitious applications of OP_CAT is enabling trust-minimized bridges between Bitcoin and Layer 2 networks. Today, most Bitcoin Layer 2 solutions (sidechains, rollups) rely on federated multisig schemes to custody funds on the base layer. With OP_CAT, a covenant script could verify cryptographic proofs on-chain, allowing a rollup to settle directly to Bitcoin without trusting a federation.

StarkWare has published a proof-of-concept bridge covenant demonstrating how a ZK-rollup could use OP_CAT to verify STARK proofs within Bitcoin Script. This would allow Layer 2 systems to inherit Bitcoin's security model rather than relying on honest-majority assumptions. The Bitcoin Layer 2 comparison covers how different scaling approaches handle trust assumptions.

Recursive Covenants and On-Chain State

Recursive covenants use OP_CAT to create scripts that enforce their own continuation: the spending transaction must include an output with the same (or an updated version of the same) covenant script. This enables stateful smart contracts on Bitcoin, where a UTXO carries state that evolves across multiple transactions.

Applications include on-chain counters, token protocols where rules are enforced by the script itself rather than external indexers, and joinpool constructions like Ark that coordinate shared UTXOs among many participants.

Post-Quantum Signature Verification

OP_CAT enables Winternitz One-Time Signatures (WOTS) within Bitcoin Script, providing a path to quantum-resistant transaction verification. WOTS signatures can be constructed and verified using only hash operations and concatenation, fitting within OP_CAT's capabilities. Developers have demonstrated working prototypes at approximately 2,000 virtual bytes per input, which is feasible though larger than standard Schnorr-based transactions. For context on quantum threats to Bitcoin, see the Shor's algorithm glossary entry.

Token Protocols and Advanced Contracts

Developers have demonstrated fungible tokens, NFT trading, and multi-party contracts using OP_CAT on test networks. Unlike existing token standards such as BRC-20 or Runes that rely on off-chain indexers to interpret meaning, OP_CAT-based tokens can have their rules enforced directly in Bitcoin Script, reducing trust assumptions.

The Activation Debate

BIP-347's specification status is "Complete," meaning the technical design is finalized. However, activation on mainnet requires a separate soft fork deployment with miner signaling, and no activation parameters have been set.

Testing and Development

OP_CAT has been enforced on the Bitcoin Inquisition signet since May 2024, providing a live testing environment for developers. A dedicated test network called Catnet also exists for OP_CAT-specific experiments. Multiple teams have built working prototypes on these networks, including bridge covenants, vault constructions, and token contracts.

Community Sentiment

Developer sentiment has trended positive, with endorsements from StarkWare, backing from Taproot Wizards (who raised $30 million in 2025 to build OP_CAT ecosystem applications), and few remaining technical objections to the opcode itself. The Quantum Cats NFT campaign served as a cultural rallying point for the proposal.

Opposition centers on several concerns: covenants could create permanently restricted UTXOs that complicate Bitcoin's fungibility, the opcode expands protocol complexity, and the appropriate activation methodology is contested. Some community members argue that proposals lacking overwhelming consensus should not use Speedy Trial (the activation mechanism used for Taproot).

Competing Proposals

OP_CAT exists alongside other covenant proposals, each with different tradeoffs:

• OP_CTV (BIP-119): narrower scope, restricts outputs to a specific template. Considered safer but less expressive than OP_CAT.
• LNHANCE: a package combining OP_CTV with other opcodes, focused on Lightning Network improvements including eltoo and channel factories.
• OP_CHECKCONTRACTVERIFY (BIP-443): an alternative covenant mechanism with different expressiveness characteristics.

The community debates whether to activate one proposal, several, or a combination. As of 2026, the broader conversation has been described as a "Bitcoin Covenant Renaissance," with multiple proposals advancing in parallel but none yet activated on mainnet.

Why It Matters

OP_CAT represents a minimal change with outsized implications. Adding a single, well-understood opcode with clear safety bounds (the 520-byte limit) could enable an entire class of functionality that currently requires either trusted intermediaries or more invasive protocol changes. For the Bitcoin Script programmability ecosystem, it is one of the most efficient paths from where Bitcoin is today to where developers want it to be.

Layer 2 protocols like Spark and Lightning already extend Bitcoin's capabilities off-chain. OP_CAT would strengthen these systems by enabling trust-minimized bridges and more expressive on-chain enforcement of off-chain state, reducing reliance on federated or cooperative assumptions.

Risks and Considerations

Fungibility Concerns

Covenants introduce the possibility of permanently restricted UTXOs: coins that can only be spent under specific conditions, potentially forever. Critics argue this creates a class of "tainted" Bitcoin that undermines the fungibility property where every satoshi is interchangeable with every other.

Complexity and Attack Surface

While OP_CAT itself is simple, the constructions it enables (recursive covenants, rollup verification, stateful contracts) are complex. Bugs in covenant scripts could lock funds permanently or create unexpected economic incentives. The expressiveness that makes OP_CAT powerful also makes it harder to reason about the full range of possible behaviors.

Activation Risk

Any consensus change to Bitcoin carries deployment risk. A contentious activation could divide the network or set precedents for how future upgrades are deployed. The Bitcoin community generally favors overwhelming consensus before activating soft forks, and OP_CAT has not yet reached that threshold.

No Activation Timeline

Despite the BIP being in "Complete" status, no mainnet activation parameters have been proposed. Developers building on OP_CAT today are working on test networks with no guarantee of when (or whether) the opcode will be available on Bitcoin mainnet. Applications designed around OP_CAT should account for this uncertainty.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.