OP_CAT is a proposed Bitcoin Script operation that concatenates two stack elements. If the stack contains x1 followed by x2, OP_CAT produces x1 || x2: the bytes of the first value followed by the bytes of the second.
The operation is simple. Its status is not. OP_CAT existed in early Bitcoin software, was disabled in 2010, and is not an active concatenation operation under Bitcoin's current mainnet consensus rules. BIP 347 proposes enabling it only in Tapscript through a soft fork.
As of July 24, 2026, BIP 347 is marked Complete, not Deployed. Under the current BIP process, Complete means the authors consider the proposal finished and recommend adoption; it does not mean activation criteria have been met or the network enforces the proposal.
Concatenation is a general building block
Bitcoin Script operates on byte arrays placed on a stack. Many useful constructions require building a larger byte sequence from smaller pieces before hashing or checking it. OP_CAT supplies that primitive.
For example, a script could concatenate two child hashes before hashing the result to verify one level of a Merkle tree. A script could combine fields that form a committed message. More elaborate constructions can use concatenation with signatures and hashes to reason about transaction data or enforce relationships among values.
OP_CAT does not understand Merkle trees, vaults, covenants, signatures, or bridges. It only joins bytes. The higher-level behavior comes from the complete script, transaction structure, signing rules, and application protocol.
This is why a small opcode can have a large design surface. General primitives can be composed in ways that are useful, inefficient, subtle, or unsafe.
Early Bitcoin had OP_CAT
The original Bitcoin Script implementation included OP_CAT. In August 2010, a commit disabled OP_CAT together with several other opcodes.
The BIP describes a historical concern that repeated duplication and concatenation could grow a stack item rapidly. Early software already had a stack-element limit, but disabling the opcode removed that construction from active script evaluation.
History should not be used as proof that the current proposal is automatically safe or unsafe. Today's Tapscript has different upgrade mechanics and explicit resource limits. BIP 347 specifies a 520-byte maximum resulting element, so a concatenation that would exceed that size fails.
The proposal is therefore a new activation decision with current semantics, not simply a switch that restores every aspect of a 2009 implementation.
Current legacy and SegWit v0 behavior
In current Bitcoin Core v31.1, OP_CAT remains in the list of disabled opcodes for legacy Script and SegWit version-zero execution. Encountering it causes script failure with SCRIPT_ERR_DISABLED_OPCODE.
BIP 347 explicitly preserves that behavior. Its proposed change applies only to Tapscript, the script language used for Taproot script-path spends.
That boundary prevents a successful soft fork from silently changing old script versions. A transaction using OP_CAT in a legacy or P2WSH script would remain invalid under the proposal.
Bitcoin Core source is evidence of one current implementation's enforcement of active rules. The consensus definition also comes from the behavior compatible nodes jointly enforce. A pull request or experimental branch that implements OP_CAT does not change mainnet consensus by itself.
Current Tapscript treats byte 0x7e as OP_SUCCESS126
Tapscript reserves a set of opcode values called OP_SUCCESSx. Under BIP 342, validation succeeds immediately if decoding encounters any OP_SUCCESSx byte, even in an unexecuted branch, before ordinary execution or later resource checks.
The historical OP_CAT byte value is decimal 126, or hexadecimal 0x7e. In current Tapscript that value is OP_SUCCESS126, not an active concatenation instruction.
BIP 347 proposes redefining OP_SUCCESS126 as OP_CAT. That is a soft-fork pattern because some spends that are valid under the old OP_SUCCESS behavior would become invalid unless they satisfy the new OP_CAT rules. Upgraded nodes would enforce the additional restrictions.
Before activation, developers must not construct a mainnet Tapscript expecting 0x7e to concatenate data. Its current success behavior is materially different and could make an output spendable under conditions the author did not intend.
The proposed operation has narrow semantics
Under BIP 347, OP_CAT would:
- require at least two stack elements;
- remove the top two elements;
- concatenate them in stack order;
- reject a result larger than 520 bytes; and
- push the result back onto the stack.
The proposal does not increase the 520-byte stack-element limit. It does not activate OP_CAT in non-Tapscript scripts. It does not define a new signature hash, inspect a transaction directly, or create persistent contract state.
The reference implementation and test vectors are part of the BIP's Complete status. Those artifacts support implementability and edge-case review. They do not supply network activation.
Complete is not Deployed
BIP 3 defines the current BIP workflow. It says that individual BIPs do not define Bitcoin or represent community consensus. A Specification BIP may move to Complete after planned work, a reference implementation, and comprehensive test vectors are available.
A Complete BIP can remain Complete indefinitely. To move to Deployed, evidence of active use is required. For a consensus soft fork, relevant evidence can include activation criteria having been met on the network.
BIP 347's changelog records that it was marked Complete on March 1, 2026. Its header still says Complete as of July 24, 2026. Therefore the accurate description is “a complete soft-fork proposal,” not “an activated Bitcoin opcode.”
Discussion, code review, signet experiments, alternative clients, or miner signaling can all be relevant to evaluation. None should be collapsed into deployment unless the actual activation mechanism and active-chain state support that claim.
Why developers are interested in OP_CAT
Concatenation can help scripts verify hashed data structures. A Merkle proof, for example, repeatedly combines a current hash with a sibling hash before hashing the pair. Native concatenation can make such verification more direct.
BIP 347 also lists tree signatures, non-equivocation contracts, Lamport-signature constructions, Bitstream, vaults, covenant techniques, and BitVM improvements as possible uses.
These are capability arguments, not deployed applications. Each construction has additional assumptions, transaction formats, limits, and security analysis. A proposal enabling one primitive does not guarantee that every cited use is practical, private, efficient, or safe.
Some examples rely on cryptographic techniques that may be difficult to review. Others can create scripts or witnesses that are large enough to be costly despite remaining within consensus limits. Application-level feasibility should be measured with concrete transactions and adversarial tests.
OP_CAT and covenants
A covenant restricts how a Bitcoin output may be spent, often by constraining properties of later transactions. OP_CAT is frequently discussed as a path to covenant-like constructions because concatenation can help scripts assemble messages checked by signature or hash operations.
OP_CAT is not itself a covenant opcode. It does not directly expose all fields of the spending transaction. Covenant behavior arises only when OP_CAT is combined with existing signature semantics and a carefully designed script.
This matters for both capability and risk claims. Saying “OP_CAT enables covenants” can hide which covenant pattern, what transaction commitments it relies on, whether key-path spending is disabled, how fees are handled, and whether the construction is usable within resource limits.
Competing covenant proposals may offer more specialized semantics. The tradeoff is not simply more versus less expressiveness. Reviewers compare analyzability, implementation complexity, composability, resource cost, accidental behavior, and interaction with existing Script rules.
Resource limits still shape applications
The proposed 520-byte result limit prevents unbounded stack-item growth inside one operation. Tapscript also has stack-element count, witness-weight, and signature-operation constraints.
A script can be consensus-valid yet expensive to create or spend. More witness data increases transaction weight and fees. More complicated scripts create more opportunities for implementation mistakes, wallet incompatibility, and poor recovery behavior.
Consensus resource limits are not a performance guarantee. Nodes still parse and execute scripts, wallets still construct witnesses, and users still need transactions to relay and confirm under current policy and fee conditions.
The BIP's safety argument should therefore be considered alongside benchmark results, code review, fuzzing, test vectors, and analysis of realistic applications.
Experimental implementations do not change mainnet
A Bitcoin Core pull request, fork, signet, or testing environment can implement BIP 347 so developers can build test scripts and measure behavior. Such software is useful evidence.
It remains implementation behavior on that environment. Mainnet users running ordinary current software do not gain OP_CAT semantics because a test branch exists.
Applications should pin the network and rules they expect. A script created for a custom signet can be misleading or unsafe if copied to mainnet. Wallets and explorers also need context-aware disassembly so they do not label current OP_SUCCESS126 behavior as activated OP_CAT.
The same byte can have different meaning across script versions and networks. Tooling must display that context rather than showing only the mnemonic preferred by one experimental implementation.
Activation would require coordinated rule enforcement
BIP 347 specifies semantics but contains no activation height, signaling threshold, start time, or deployment parameters. Bitcoin Core v31.1 sources reviewed for this guide preserve active OP_SUCCESSx Tapscript behavior and legacy or SegWit v0 disabled-opcode behavior; they do not document a mainnet BIP 347 deployment. Any mainnet deployment would need a concrete soft-fork activation process, implementation releases, ecosystem review, and a point at which upgraded nodes begin enforcing the new rule.
A soft fork is backward-compatible in the limited sense that old nodes can continue accepting blocks that upgraded nodes accept. Old nodes would not enforce the new OP_CAT restrictions and could not independently validate that a Tapscript spend complied with them.
That creates the ordinary soft-fork dependence on sufficient enforcement by the economic network. The risks and decision process are broader than whether the opcode implementation passes unit tests.
No guide should predict activation dates, claim consensus, or describe a proposal as inevitable. Bitcoin has no central body that can approve a BIP into consensus.
The practical evaluation
When evaluating OP_CAT, begin with the active network rule: current mainnet Tapscript uses OP_SUCCESS126, while legacy and SegWit v0 OP_CAT remain disabled.
Then read the exact BIP version and status. BIP 347 version 1.0.0 is Complete as of the review date, which establishes proposal maturity under the BIP process but not deployment.
Next examine the reference implementation, tests, benchmarks, and specific use case. Verify witness sizes, fees, key paths, recovery paths, and behavior if a transaction is delayed or replaced.
Finally separate the primitive from the product claim. OP_CAT concatenates bytes. A vault, bridge, post-quantum fallback, BitVM optimization, or covenant system must be evaluated as its own protocol.
That disciplined description leaves room for serious interest without presenting a proposed consensus change as a feature users can rely on today.