Where Does OP_CAT (BIP-347) Stand in 2026? Will It Activate?

Bitcoin · 2026-06-05 · 比特三棱镜编辑部
Ask AI

If you first heard about OP_CAT back in 2024, you would have been forgiven for filing it under “another proposal stuck in review forever.” By mid-2026 that filing is wrong. BIP-347 has its official number, three independent node implementations exist (a Bitcoin Core experimental branch, btcd, Bitcoin Knots), and a notable cluster of researchers — Tadge Dryja, Olaoluwa Osuntokun of Lightning Labs, Andrew Poelstra of Blockstream — have gone on record supporting it. Teams like Taproot Wizards, Botanix Labs and Citrea now plan their roadmaps assuming OP_CAT will land.

None of this means OP_CAT is live on mainnet. It is not. But the conversation has clearly shifted from “is this a real proposal” to “what activation path do we use,” and that is a meaningful change. This piece walks through the actual 2026 status, item by item, without inflating it.

OP_CAT BIP-347 development progress diagram for 2026, showing code commits, node implementations and community debate threads converging on a single timeline

What OP_CAT Does and Why It Was Disabled

OP_CAT is one of the oldest opcodes in Bitcoin. It was present in v0.1 with a straightforward job: pop the top two byte strings off the script stack, concatenate them, push the result back. Boring in isolation, but if a script can concatenate bytes, it can also build, check and compare arbitrary structured data — not just signatures and hashes.

Satoshi disabled OP_CAT in August 2010 alongside several other opcodes. The reason was operational: stack element length was unbounded, so a loop of OP_DUP + OP_CAT could grow an element exponentially and OOM a node. It was part of a sweep targeting “anything that could blow up a node,” not a comment on OP_CAT’s semantics.

Taproot (2021, BIP-342 tapscript) changed the constraints. Tapscript enforces a hard 520-byte cap on stack elements, which structurally prevents the exponential-blowup attack. Re-enabling OP_CAT under tapscript is therefore engineering-feasible — that is precisely what BIP-347 specifies.

Where BIP-347 Actually Is in 2026

The proposal’s title is “OP_CAT in Tapscript”, authored by Ethan Heilman and Armin Sabouri. The condensed timeline:

  • Oct 2023: first draft circulated on the mailing list.
  • Early 2024: Taproot Wizards drove a community-awareness push.
  • Mid-2024: BIP editors assigned number 347, status moved to Draft.
  • 2025: experimental Bitcoin Core branch; btcd and Bitcoin Knots ship independent implementations; cross-implementation fuzzing begins.
  • Q1 2026: status advanced to Proposed; activation-mechanism debate (BIP-9 vs BIP-8 vs Speedy Trial variants) opens on Delving Bitcoin and the bitcoin-dev list.
  • May 2026: multiple Bitcoin Core forks ship the tapscript-only OP_CAT as a build flag, not in mainnet consensus.

A BIP number, by itself, does not mean activation. It only signals that the document is technically coherent enough to keep discussing. Getting from “Proposed” to live consensus still requires three things: agreement on the activation path, node-upgrade coverage, and a miner signal (if any BIP-9-style mechanism is chosen). None of those is done.

Why Dryja, Osuntokun and Poelstra All Show Up Now

OP_CAT was niche inside the core research crowd before 2023. It looked “too simple” to justify a dedicated soft fork. Three research threads changed that:

  1. Covenants, minimally. Covenants — scripts that constrain what the next spending transaction must look like — are usually proposed as dedicated opcodes (OP_CTV, APO, TXHASH). Poelstra’s 2024 talk Symbolic Computation in Bitcoin Script showed that OP_CAT plus OP_SHA256 and OP_CHECKSIG can simulate most of what those dedicated opcodes do, without expanding the consensus surface.
  2. BitVM and ZK verification. Dryja’s and Robin Linus’s BitVM work needs a lot of in-script byte-string concatenation and hash chaining. Without OP_CAT this has to be emulated via bit commitments, which currently costs tens of KB of witness data per on-chain verification. OP_CAT cuts that footprint dramatically.
  3. Lightning and channel upgrades. Lightning Labs is on record that OP_CAT is a practical prerequisite for productionizing PTLCs and several cross-channel protocols.

Put plainly, OP_CAT is not a feature — it is a primitive, and many camps benefit. That is why the support coalition is broader than for any post-Taproot proposal so far.

Objections and a Realistic Activation Estimate

You should hear the pushback too:

Objection Source Stands up?
Exponential string growth crashes nodes Historical Tapscript’s 520-byte cap closes this — does not stand
Covenants make coins less fungible Luke Dashjr et al. Philosophical; not technically falsifiable
Miner incentive shifts Some mining pools No empirical evidence yet
No agreement on activation mechanism bitcoin-dev list Stands — this is the real bottleneck

The last row is what actually matters. Bitcoin has not had a successful soft fork since Taproot in 2021, and there is no settled view on which activation mechanism to use next. Speedy Trial worked once; Drivechain, CTV and APO all stalled in this same gate. OP_CAT, even technically ready, will hit the same wall.

If you want broader context on Bitcoin L2 dynamics, see my earlier Real Bitcoin L2 Use Cases in 2026 — Citrea and Botanix both treat OP_CAT as a “switch on the day it activates” dependency. The piece on Bitcoin Hyper, an SVM-based L2 also touches on how covenants matter differently in different L2 models.

What This Means for Developers vs Holders

Developers: you can already build against OP_CAT on signet or mutinynet today. Taproot Wizards run a network called cat-signet; Citrea enabled OP_CAT on its devnet. If you are writing BitVM-style scripts, prototyping there is dramatically faster than waiting for mainnet.

Regular holders: there is nothing for you to do right now. Even after activation OP_CAT is a soft fork — old nodes do not split off, wallets do not need to upgrade. The moment to actually pay attention is when the activation-mechanism debate resolves: either a BIP-9-style signal window opens, or a client-driven flag-day proposal reaches enough adoption.

On current pace, mainnet activation is a 2027 event at the earliest, with a more honest median in late 2027 to 2028. Any narrative claiming “OP_CAT is shipping this year” is marketing. Reaching a BIP number, getting multiple implementations and earning serious researcher backing only moves OP_CAT from “can this be done” to “when and how.” The gap between those phases, in Bitcoin’s deliberately conservative governance culture, is measured in years.

A comparison diagram of BIP-347 implementation paths, with Bitcoin Core mainline on the left and cat-signet plus Citrea devnet enabled branches on the right

Signals Worth Tracking

If you do not want to read bitcoin-dev daily, narrow your attention to these four signals:

  • bitcoin-dev list activity on activation mechanics (keywords: BIP-8, LOT=true/false, flag day).
  • Delving Bitcoin OP_CAT and covenants sub-forum monthly activity.
  • Bitcoin Core review club putting the BIP-347 implementation PR on its formal review agenda.
  • Citrea mainnet (live since 2026-01-27) or Botanix publishing a concrete “OP_CAT-ready” switch plan.

All four warming up at once is a real signal. Twitter heat alone is noise. OP_CAT’s position in 2026 is neither a finish line nor a hype cycle — it is the first time since Taproot that the old, slow machinery of Bitcoin soft-fork governance has audibly started humming again.