OP_SUCCESS Opcodes

What Are OP_SUCCESS Opcodes?

OP_SUCCESS opcodes are a set of reserved opcodes in Tapscript that make an entire script pass unconditionally when encountered. Defined in BIP 342, they serve as upgrade hooks: empty slots where future soft forks can introduce new functionality without breaking existing consensus rules.

Before Taproot, Bitcoin upgraded its scripting system by repurposing OP_NOP opcodes. That approach had a fundamental limitation: redefined OP_NOP opcodes could only add new conditions that cause a script to fail. They could not read from or write to the stack, which severely limited what new opcodes could do. OP_SUCCESS opcodes solve this by working in the opposite direction: they start by making scripts succeed, and a soft fork narrows that behavior by adding validation logic that can reject previously valid scripts.

The name reflects this behavior. An OP_SUCCESSx opcode signals unconditional success, just as OP_RETURN signals unconditional failure. Until a soft fork assigns real semantics, the opcode is a blank pass.

How It Works

When a node encounters a Tapscript for validation, it scans the script bytes before executing any instructions. If any byte matches an OP_SUCCESSx opcode number, the script is marked as valid immediately. No further decoding or execution takes place.

1. A transaction spending a script-path Taproot output is broadcast to the network
2. Nodes decode the Tapscript and scan for OP_SUCCESSx opcodes during the initial parse phase
3. If an OP_SUCCESSx is found anywhere in the script (even inside an unexecuted branch), the entire script succeeds without further validation
4. Because success is determined at parse time, bytes after the OP_SUCCESSx opcode do not need to be valid script

This parse-time evaluation is the key design choice. Because the opcode is detected before execution begins, a future soft fork can redefine the opcode to perform any operation on the stack: reading elements, pushing new values, or failing based on arbitrary conditions. There are no constraints inherited from the old interpretation.

The OP_SUCCESS Opcode Numbers

BIP 342 designates the following opcode values as OP_SUCCESSx, drawn from previously disabled or undefined slots in Bitcoin Script:

OP_SUCCESS80   (0x50)
OP_SUCCESS98   (0x62)
OP_SUCCESS126  (0x7e)  through  OP_SUCCESS129  (0x81)
OP_SUCCESS131  (0x83)  through  OP_SUCCESS134  (0x86)
OP_SUCCESS137  (0x89)  through  OP_SUCCESS138  (0x8a)
OP_SUCCESS141  (0x8d)  through  OP_SUCCESS142  (0x8e)
OP_SUCCESS149  (0x95)  through  OP_SUCCESS153  (0x99)
OP_SUCCESS187  (0xbb)  through  OP_SUCCESS254  (0xfe)

These opcodes collectively provide dozens of slots for future upgrades. Each can be independently redefined by a separate soft fork, giving the Bitcoin protocol a large reserve of extensibility within Tapscript.

OP_SUCCESS vs. OP_NOP Upgrades

Understanding the difference between these two upgrade mechanisms is essential for grasping why OP_SUCCESS matters. In legacy Bitcoin Script, new opcodes were added by redefining OP_NOP instructions:

The OP_NOP limitation meant that opcodes like OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY could only verify conditions and abort the script on failure. They could never push results onto the stack or consume inputs. OP_SUCCESS removes this constraint entirely.

The Soft Fork Upgrade Process

When the Bitcoin community agrees to add a new opcode via OP_SUCCESS, the process follows a well-defined pattern:

1. A Bitcoin Improvement Proposal (BIP) is drafted specifying the new opcode's behavior, including which OP_SUCCESSx slot it will replace
2. The proposal undergoes review, testing on signet or testnet, and community discussion
3. Once consensus is reached, a soft fork activation mechanism deploys the change
4. After activation, nodes running the new software validate the opcode according to its new rules: scripts that previously succeeded unconditionally may now fail if they do not satisfy the new validation logic
5. Older nodes that have not upgraded continue to see the OP_SUCCESSx opcode and accept the script unconditionally, maintaining backward compatibility

This is why the mechanism works as a soft fork: it only tightens the rules. Scripts that the new opcode rejects were already "anyone can spend" under the old rules, so rejecting them does not invalidate any previously final transaction. Only new transactions using the redefined opcode are subject to the stricter validation.

Use Cases

OP_CAT (BIP 347)

The most prominent proposal to use the OP_SUCCESS mechanism is OP_CAT, specified in BIP 347. This proposal would redefine OP_SUCCESS126 (opcode 0x7e, the same slot the original OP_CAT occupied before it was disabled) to concatenate the top two stack elements. Though the operation sounds simple, concatenation is a foundational primitive that enables covenants, transaction introspection, and on-chain verification of Merkle proofs. As of late 2026, BIP 347 has a complete specification and has been tested on Bitcoin Inquisition signet, but no activation parameters have been defined.

Future Script Enhancements

The OP_SUCCESS slots are not limited to any single category of opcode. Proposals under discussion or development include:

• OP_TXHASH: would allow scripts to hash selected parts of a transaction, enabling flexible introspection and covenant patterns
• OP_PAIRCOMMIT: would create a commitment to a pair of stack elements, useful for building more complex script logic
• Arithmetic and cryptographic opcodes: proposals to add 64-bit arithmetic, new hash functions, or signature verification schemes could each claim an OP_SUCCESS slot

Each proposal would consume one OP_SUCCESS slot permanently, which is why there are dozens of reserved slots available.

Extending Bitcoin Programmability

By providing a clean upgrade path, OP_SUCCESS opcodes directly influence the trajectory of Bitcoin Script programmability. Features that would have been impossible under the OP_NOP model (because they require stack manipulation) become straightforward candidates for soft fork activation. This includes advanced spending conditions, vault constructs like OP_VAULT, and programmable covenants that could improve custody and security for self-custodial wallets and layer-2 protocols like Spark.

Risks and Considerations

Using OP_SUCCESS Before Redefinition Is Insecure

BIP 342 explicitly warns that using an OP_SUCCESSx opcode in a script before it has been redefined by a soft fork leads to fund loss. Because any script containing the opcode succeeds unconditionally, anyone can spend funds locked by such a script. The opcode is a placeholder, not a security primitive. Wallet software must never produce scripts containing undefined OP_SUCCESSx opcodes.

Finite Upgrade Slots

While BIP 342 provides a generous number of OP_SUCCESS slots, the supply is finite. Each slot can only be redefined once, so the Bitcoin community must be selective about which opcodes to add. Poor choices consume a slot permanently without delivering proportional value. This is one reason why opcode proposals undergo extensive review and debate before activation.

Backward Compatibility Trade-offs

OP_SUCCESS opcodes exist only in Tapscript, not in legacy or SegWit v0 scripts. Scripts using older output types (P2PKH, P2SH, P2WPKH) cannot benefit from this upgrade mechanism. Future opcode enhancements are therefore limited to Taproot outputs, which further incentivizes migration to P2TR address types.

Consensus on Activation

Having available OP_SUCCESS slots does not guarantee that proposals will be activated. Each redefinition requires a soft fork, which demands broad community consensus. The OP_CAT debate illustrates how proposals can remain in discussion for years even when the specification is technically complete, as disagreements about downstream implications (such as covenant risks or fungibility concerns) slow the path to deployment.

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.