WTF is OP_CAT? Why Should We Care? // Aayush Giri

OP_CAT is opcode 0x7e. It pops two items off the stack and pushes their concatenation. It shipped in Bitcoin 0.1. On August 15, 2010, in commit 4bd188c titled "misc changes", Satoshi Nakamoto silently disabled it alongside fourteen other opcodes. There was no announcement. BIP-347 is the proposal to turn it back on in Tapscript.

The reintroduction is the single most consequential script change being seriously debated for Bitcoin right now. Not because concatenation is interesting. Because OP_CAT combined with a Schnorr signature quirk gives Bitcoin Script transaction introspection. Transaction introspection is another name for covenants. Covenants are the primitive every serious Bitcoin layer-2 team is waiting on.

What OP_CAT Actually Does

The specification is one sentence. Given a stack [x1, x2] with x2 on top, OP_CAT pushes x1 || x2. It fails if there are fewer than two items on the stack or if the result exceeds 520 bytes. Nothing else.

BIP-347's reference implementation is twelve lines of C++. It is structurally close to the version Satoshi shipped in 2009. The two material differences are that it checks the result size against MAX_SCRIPT_ELEMENT_SIZE = 520 before writing back to the stack (the original checked 5000 bytes after the write), and it returns specific script error codes instead of a bare false.

bip-347 reference implementation

case OP_CAT:
{
  if (stack.size() < 2)
    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
  valtype& vch1 = stacktop(-2);
  valtype& vch2 = stacktop(-1);
  if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
    return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
  vch1.insert(vch1.end(), vch2.begin(), vch2.end());
  stack.pop_back();
}
break;

Activation reuses opcode value 126 (0x7e), the slot OP_CAT originally occupied. Post-Taproot, 0x7e is currently defined as OP_SUCCESS126. BIP-342 shipped the OP_SUCCESSx mechanism specifically so future soft forks could redefine currently-no-op opcodes without consuming a new byte. BIP-347 is the cleanest possible exercise of that mechanism: same name, same byte, same semantics, one new safety check.

Why Satoshi Removed It in 2010

Folklore says OP_CAT was removed because a crafted script could blow the stack up exponentially. Push a one-byte value, then alternate OP_DUP and OP_CAT forty times, and the top stack element is larger than one terabyte. That pattern is real. The folklore is only half the story.

Bitcoin in August 2010 already had a per-element stack cap of 5000 bytes. The terabyte figure assumes that cap does not exist. In practice a node running 0.3.9 would have rejected the oversized element well before it did any damage. BIP-347 acknowledges this directly: the removal was a blanket precaution, not a considered response to an exploit.

The commit itself is labelled "misc changes." It disabled OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, and OP_RSHIFT. The disable for OP_VERIF and OP_VERNOTIF sits elsewhere in the script interpreter and predates this commit. Satoshi shipped the misc-changes rollup in 0.3.10 and moved on. There is no mailing-list thread, no design document, no rationale. It is one of the quietest consensus changes in Bitcoin's history.

Why Tapscript Makes It Safe

Taproot activated on Bitcoin mainnet in November 2021. Two features of the surrounding script system matter for OP_CAT. Tapscript enforces a 520-byte maximum stack element size (MAX_SCRIPT_ELEMENT_SIZE has been part of Bitcoin's script rules since long before Taproot; Tapscript continues to enforce it). And BIP-342 defines OP_SUCCESSx, a set of opcode slots that pass by default today and can be redefined to arbitrary behavior via a future soft fork.

Those two features together defuse the 2010 concern structurally. An OP_DUP plus OP_CAT loop doubles the top stack element on every iteration. Starting from one byte, the tenth doubling crosses 520 bytes and the script aborts. The exponential blow-up is not a design question anymore. It is a thing the interpreter cannot do.

The Timeline: BIN-2024-0001, BIP-420, BIP-347

Ethan Heilman and Armin Sabouri authored the spec. Heilman posted the draft to the bitcoin-dev list on October 21, 2023. The Bitcoin Inquisition Numbers And Names Authority assigned it BIN-2024-0001 in January 2024. The BIP editors moved more slowly. Luke Dashjr, then a sitting BIP editor, had been holding up several active proposals citing a lack of broad support.

Taproot Wizards co-founders Eric Wall and Udi Wertheimer responded in April 2024 with a meme campaign to force the issue, lobbying for the number BIP-420. The campaign worked, indirectly. Ava Chow's proposal to add more BIP editors landed in the same window. On April 24, 2024, OP_CAT was officially assigned BIP-347. The spec merged to the bitcoin/bips repository on May 6, 2024.

BIP-420 is not OP_CAT. It is a separate informal covenants proposal that the bip420 GitHub group continues to maintain. Crypto press has conflated the two often enough to be worth saying out loud once. The canonical OP_CAT proposal is BIP-347 and has been since April 2024.

The Schnorr Trick

If OP_CAT only concatenated bytes, the activation debate would not exist. What makes the opcode load-bearing is a signature verification quirk Andrew Poelstra wrote up across January and February 2021 in a pair of posts titled "CAT and Schnorr Tricks".

BIP-340 Schnorr signatures satisfy s = k + xe, where e is the tagged challenge hash H_BIP0340/challenge(R || P || m), P = xG is the public key, R = kG is the ephemeral nonce, and m is the sighash of the spending transaction. Poelstra noticed what happens if you force x = k = 1. Both P and R collapse to the generator G, and the signature equation reduces to this:

schnorr covenant reduction

BIP340 signature:     s = k + x * e
                      e = H_BIP0340/challenge(R || P || m)

Force x = 1, k = 1:
  P = G, R = G:       s = 1 + H_BIP0340/challenge(G || G || m)

Meaning of s:         a tagged SHA256 of the spending transaction data,
                      with a fixed prefix, offset by 1.

The value of s is a deterministic hash of the spending transaction with a fixed prefix that Script can compute. If a script pushes pieces of the transaction, concatenates them with OP_CAT, hashes the result, adds 1, and compares against s, it has reconstructed the sighash on the stack. Feeding the same (s, R=G) into OP_CHECKSIG with pubkey G then validates that the reconstructed bytes match the actual spending transaction.

The working script, credited to Dmitry Petukhov, is five opcodes:

petukhov covenant prelude

<G> 2DUP SWAP CAT SWAP CHECKSIG

# stack starts with:     [s]
# <G> 2DUP:               [s, G, s, G]
# SWAP CAT:               [s, G, G || s]
# SWAP:                   [s, G || s, G]
# CHECKSIG consumes top two as (sig = G || s, pubkey = G)
# leaves s on the stack for the rest of the script to inspect

The one wart is the +1 offset. The signature equation produces s = hash + 1, and Script has no native 256-bit addition opcode. The workaround is grinding transaction data until the sighash ends in 0x01, which lets the +1 fix-up reduce to a byte-level edit. It is annoying. It is not blocking.

Everything downstream of this trick is what people mean when they talk about OP_CAT enabling covenants. CHECKSIGFROMSTACK was never added to Bitcoin, but OP_CAT plus BIP-340 signatures emulate it. A concatenation opcode plus a signature scheme designed for a completely different purpose gives Script a capability the protocol has explicitly refused to enshrine for fifteen years.

What OP_CAT Enables

BIP-347 lists eight use cases in its motivation section. The ones that matter most are the ones several independent teams are already building against.

01Vaults. A covenant that forces a withdrawal through a timelocked path. If a signing key is compromised, the legitimate owner sees the pending spend and rotates funds to a recovery key before the timelock elapses. Moser, Eyal, and Sirer's 2016 covenants paper specified the construction. OP_CAT is sufficient to build it.
02BitVM2. Robin Linus's BitVM2 design (announced August 2024) uses a fraud-proof challenge game whose worst-case path takes many on-chain transactions. BIP-347 itself cites BitVM2 as a motivating use case: OP_CAT would let BitVM2 eliminate its trusted setup and shrink the size of the transactions it needs.
03STARK verifiers. Weikeng Chen built a Circle-STARK verifier in Bitcoin Script. In July 2024, the final transaction in a Fibonacci-squared proof chain confirmed on signet under Inquisition semantics, widely reported at the time as the first STARK verified on Bitcoin's script environment. The verifier is not production-ready. The primitive exists.
04Tree signatures. A multisignature whose script size is logarithmic in the key count. Pieter Wuille's 2015 construction scales up to 2^32 public keys, with script sizes in the hundreds-of-bytes range for practical fan-outs.
05Lamport and Winternitz signatures. Hash-based signature schemes that only need a hash function and concatenation. BIP-347 is careful to note that Taproot's key-path spend still leaks to a quantum adversary, so these do not make Bitcoin post-quantum by themselves. They are a path component, not a solution.
06Non-equivocation bonds. Payment channel constructions that penalize double-spending by forcing the attacker to reveal the key they used to sign two conflicting transactions.

None of these are new ideas. All of them have published designs from 2015-2021 that assumed either an undefined CHECKSIGFROMSTACK opcode or an unspecified introspection primitive. OP_CAT is the single missing ingredient that makes every one of them executable in Tapscript as it exists today.

Where It Already Runs

OP_CAT is not activated on Bitcoin mainnet. It is activated on two places that matter.

Fractal Bitcoin launched its mainnet on September 9, 2024 with OP_CAT activated from genesis. The CAT20 token standard, the CAT Protocol bridge, and a handful of inscription-adjacent tooling have been running against it in production since launch. Fractal is a separate chain running a hybrid SHA-256d proof-of-work model its team calls cadence mining: a portion of blocks are merge-mined with Bitcoin, the rest are produced by a permissionless Fractal-only miner set. The data Fractal produces is evidence of the opcode's behavior under load, not of Bitcoin social adoption.

Bitcoin Inquisition is a signet fork that ships proposed soft-fork opcodes under draft BIP semantics. Inquisition 27.0, released in late May 2024, began enforcing OP_CAT on signet. Every serious implementation of BIP-347-adjacent tooling, including Chen's STARK verifier and the Taproot Wizards' CatVM bridge prototype, runs against Inquisition.

The gap between "works on Fractal" and "activated on Bitcoin" is not code. It is consensus.

The Opposition

The serious objections to OP_CAT are not about the opcode. They are about the class of applications the opcode enables.

The ossification camp argues that Bitcoin's consensus rules are load-bearing because they have not changed. Luke Dashjr held this position while he was a BIP editor and declined to number OP_CAT for months on the grounds of insufficient broad support. The counter, made publicly by Andrew Poelstra among others, is that Bitcoin has already evolved through Ordinals and inscriptions without a single consensus change, so the ossification argument is defending a position the network has already left.

The MEV concern is that richer covenants enable on-chain auctions, programmable spending conditions, and layer-2 contracts that import the front-running dynamics Ethereum has spent five years trying to mitigate. Poelstra's response is that Bitcoin's mempool does not expose contract state the way an EVM block does, so the attack surface is narrower. That response does not rebut the concern. It shrinks it.

The fee concern is that more expressive scripts produce larger witnesses, which raise fees for ordinary users. This one is straightforwardly correct. The counter is that the fee market is already saturated by inscriptions and BRC-20s, neither of which required a consensus change, and OP_CAT-based applications compete for the same blockspace rather than creating new demand.

The hardest objection to answer is unintended consequences. Recursive covenants (state forced to persist across spends) are theoretically possible with OP_CAT plus a couple of other primitives. Nobody has shipped one that works. If they exist and behave badly, the damage is structural rather than reversible. The usual response is that Bitcoin Inquisition is where you find out. Roughly two years in, the live experiment has produced demos and a verified STARK proof, not disaster.

How the Pieces Fit

OP_CAT is a twelve-line C++ patch whose footprint on the Bitcoin protocol is smaller than almost any change that has been activated since SegWit. Its significance comes from a composability fact that nobody saw in 2010 and almost nobody saw until 2021: concatenation plus a signature algorithm designed for a completely different purpose gives Script transaction introspection.

That is the reason the list of teams lobbying for activation is long. Citrea gets a cheaper bridge. Starknet gets a path to settling STARK proofs on Bitcoin. BitVM2 gets to drop its trusted setup and shrink its transactions. Taproot Wizards' CatVM gets permissionless exits. Vault designers get a construction they have been writing papers about for nearly a decade. None of this requires a new opcode. It requires one opcode Satoshi turned off for reasons he did not write down.

The spec is merged. The tests pass. The implementation exists. Bitcoin has not coordinated on an activation path, and it is not obvious when or how it will. Eli Ben-Sasson told Cointelegraph in 2024 that activation within twelve months was plausible. That window has closed. The window after it is open.

WTF is OP_CAT? Why Should We Care?