Bitcoin OP_CAT Explained: What BIP 347 Actually Changes

As of 21 October 2026, Bitcoin BIP 347 is a completed specification—not an activated consensus rule. It proposes restoring OP_CAT in Tapscript, where the opcode would concatenate two stack values subject to a 520-byte limit. The change would require a soft fork. In plain English, OP_CAT would let a Bitcoin script join two byte strings; it would not make the proposal live or turn Bitcoin into a general-purpose computer. The official BIP list records BIP 347 as “Complete,” while the BIP text describes a proposed rule change. That distinction is the key fact for anyone evaluating OP_CAT.

What does OP_CAT do?

OP_CAT concatenates two values on a script stack: it takes the lower item followed by the top item and pushes the combined bytes. For example:

text

<0xB10C> <0xCAFE> OP_CAT
→ <0xB10CCAFE>

The BIP 347 specification makes the operation fail if the stack has fewer than two items or if the combined element would exceed 520 bytes. That limit matters: OP_CAT is a bounded data-composition operation, not an unbounded way to grow script values. Bitcoin Optech’s OP_CAT overview explains the byte-joining behavior, while BIP 342 defines the existing Tapscript validation rules and resource limits.

What exactly does BIP 347 propose?

BIP 347 would define OP_CAT for Tapscript by redefining the tapscript opcode OP_SUCCESS126 (0x7e). Tapscript is the script-path spending language introduced with Taproot; BIP 347 does not propose turning on the old opcode throughout every generation of Bitcoin Script. Its specification lists BIP 340, BIP 341 and BIP 342 as prerequisites.

The proposal is a soft fork: if activated, upgraded nodes would apply the new concatenation rule where the opcode appears in a Tapscript spend. The BIP’s “Complete” status means the specification text is finished; it does not mean that miners, nodes or wallets have activated the change. Bitcoin Optech notes that the original opcode was disabled in 2010 and that later versions have been proposed for soft-fork addition.

Why do developers care about concatenation?

Bitcoin Script can check signatures, hashes and other conditions, but it has limited ways to combine arbitrary pieces of data on the stack. OP_CAT supplies a small primitive that can join a value committed in a script with a value supplied by a spender, then pass the result to other script operations. Some designs can use that composition with existing script features; other proposed applications depend on additional opcodes or consensus changes. OP_CAT itself only joins bytes—it does not, by itself, add a general command for inspecting every field of a future transaction.

One area of research is vaults and other covenant-like constructions. A covenant is a spending condition that constrains how coins may be spent later. A Bitcoin Optech summary published on 2 October 2026 lists an OP_CAT-based Purrfect Vault among several simplified vault constructions being compared, alongside designs using presigned transactions and other proposed script features. That is evidence of ongoing design work, not evidence that BIP 347 has been deployed.

This is a different Bitcoin proposal from BIP 360’s proposed P2MR output, which addresses a specific long-exposure quantum-risk question. It also differs from the PQLN research prototype, which concerns selected Lightning Network layers rather than a new base-layer script rule.

What changes for Bitcoin users today?

Nothing changes for a wallet holder merely because BIP 347 is complete as a specification. The official BIP index distinguishes BIP 347’s “Complete” status from “Deployed” entries such as BIP 342. Until a consensus change is activated and tools support it, users should not assume that standard Bitcoin transactions can use OP_CAT’s proposed concatenation semantics. The BIP specifies a possible future rule; it is not a wallet upgrade instruction or a new asset feature.

For builders, the practical next step is to separate three things: the opcode’s simple byte-concatenation behavior, the larger contract patterns that might build on it, and the process required to agree and activate a Bitcoin soft fork. Reviews should focus on the complete script and its failure conditions, not on the opcode name alone.

Frequently asked questions

Is OP_CAT enabled on Bitcoin mainnet?

BIP 347 is not listed as a deployed consensus rule. Its specification is marked “Complete,” but the proposed Tapscript behavior would require a soft fork before it could be used as intended.

Does OP_CAT automatically create a Bitcoin covenant?

No. OP_CAT joins two stack values. Some covenant or vault designs may use that primitive together with other script capabilities, but the exact guarantees depend on the full construction and any additional consensus changes it requires.

What does the 520-byte limit mean?

The combined stack item must be no larger than 520 bytes. If the result would exceed that maximum, the proposed opcode fails rather than producing a larger value.

Does a completed BIP mean the change is active?

No. “Complete” describes the specification’s status in the BIP index. Activation is a separate consensus process; the BIP 342 entry, for example, is marked “Deployed.”

Sources

BIP 347: OP_CAT in Tapscript — proposed opcode behavior, 520-byte limit and soft-fork mechanism.
Bitcoin Improvement Proposals index — current BIP statuses, including BIP 347 and BIP 342.
BIP 342: Validation of Taproot Scripts — deployed Tapscript and OP_SUCCESS rules.
Bitcoin Optech: OP_CAT — historical context and examples of the opcode’s uses.
Bitcoin Optech Newsletter #425, 2 October 2026 — comparison of vault constructions, including an OP_CAT-based design.

For teams evaluating Bitcoin scripting or wallet integrations, contact SignorCrypto to scope protocol compatibility, security review and implementation trade-offs before a build.