OP_SUCCESS (Tapscript)

OP_SUCCESS opcodes are Tapscript's built-in upgrade hooks, defined in BIP 342 as part of the Taproot soft fork. A range of previously unused or disabled opcode numbers — 80, 98, 126–129, 131–134, 137–138, 141–142, 149–153, and 187–254 — are renamed OP_SUCCESS80 through OP_SUCCESS254. If a Tapscript contains any of them anywhere in its body, validation succeeds unconditionally: the script is not even executed, and later bytes that would otherwise fail to decode are ignored. It is the most permissive behaviour in all of Bitcoin Script, and it exists entirely for the benefit of future soft forks.

How unconditional success enables upgrades

A soft fork tightens rules: transactions valid under the new rules must also look valid to old nodes. OP_SUCCESS is engineered for exactly that shape. Today, a script containing OP_SUCCESS187 passes automatically. A future soft fork can redefine opcode 187 to perform real work — with full read and write access to the stack — and old nodes will still accept every transaction the new rule accepts, because to them the script succeeds regardless. The new opcode can be anything: a fresh arithmetic instruction, a covenant primitive, a multi-byte opcode where 187 acts as a prefix, or even the entry point to an entirely different scripting language. Because success is decided at parse time rather than execution time, upgrades are not constrained by where in the script the new opcode sits or whether surrounding bytes decode under old rules.

Why this beats the legacy OP_NOP approach

Before Taproot, upgrade space came from ten OP_NOP opcodes, which do nothing and must leave the stack untouched. That constraint is severe: a redefined NOP can only verify something and abort on failure — the pattern behind OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY, both of which had to be awkwardly designed to inspect state without modifying it. OP_SUCCESS removes the handcuffs. A redefined success opcode may push results, consume arguments, and change semantics freely, because old nodes never execute the script at all. This is a strictly larger design space bought at the cost of a stranger default behaviour.

A safety caveat for script authors

The generosity cuts both ways. Until an OP_SUCCESS number is redefined, its presence makes a script spendable by anyone — the script passes with no signatures checked and no conditions met. Anyone hand-assembling a Tapscript leaf must therefore treat these opcodes as radioactive unless deliberately intended: a single stray byte in the success ranges turns a vault script into a donation. Well-behaved wallet software and script compilers refuse to emit them, and standardness rules discourage relaying spends that rely on them, but a raw-script author enjoys no such guardrails. Verify your script bytes against the reserved ranges before committing funds — the same measure-twice discipline you would apply before flashing firmware to a hashboard controller.

Place in the Taproot architecture

Standardness policy adds a pragmatic buffer on top of consensus: current nodes treat transactions spending scripts that contain OP_SUCCESS opcodes as non-standard and refuse to relay them, a discouragement that keeps the upgrade space pristine without making such spends invalid. A miner could still include one directly, which is why the burden stays on script authors to avoid the reserved bytes rather than on the network to police them — consensus stays minimal, policy carries the guardrails.

OP_SUCCESS is one half of Tapscript's forward-compatibility story; the other half is leaf versioning in the Taproot control block, which reserves whole script-version numbers for future languages. Between the two, Bitcoin gained layered upgrade paths that require no disruptive hard fork. The mechanism shares its execution environment with the redefined OP_CHECKSIG and the new OP_CHECKSIGADD, and its resource accounting falls under the same sigop budget that governs all Tapscript spends. For the sovereign node operator, OP_SUCCESS is a quiet promise: the protocol can keep evolving by consensus, and your node — not any coordinating authority — decides when a new meaning for those bytes becomes law.