Tapscript Opcode Budget

What Is the Tapscript Opcode Budget?

The Tapscript opcode budget refers to the set of resource limits that BIP 342 defines for scripts executed inside Taproot outputs. Before Taproot, legacy and SegWit v0 scripts operated under rigid constraints: a maximum of 201 non-push opcodes per script, a 10,000-byte script size cap, and a block-wide signature operations limit of 80,000 (weighted). These limits were blunt instruments designed to prevent denial-of-service attacks, but they also restricted what developers could build with Bitcoin Script.

Tapscript replaces these constraints with a more flexible system. The opcode count limit and the script size cap are removed entirely. In their place, BIP 342 introduces a per-input signature operations budget that scales with the size of the input's witness data. This design preserves DoS protection while unlocking new capabilities: larger multisig setups, more conditional branches, and scripts that would have been impossible under the old rules.

How It Works

Tapscript's resource model rests on a simple principle: the cost of validating a script should be proportional to the data the spender puts on-chain. Since witness data contributes to weight units and therefore to the fee a transaction pays, tying the budget to witness size means that more expensive scripts cost more to broadcast.

Removed Limits

Two legacy limits are explicitly dropped for Tapscript execution:

• The maximum non-push opcodes limit of 201 per script does not apply. In legacy and SegWit v0 scripts, every opcode that is not a data push counts toward a hard cap of 201. Exceeding it makes the script invalid. Tapscript removes this restriction, so scripts can contain any number of operations, bounded only by the block weight limit.
• The maximum script size of 10,000 bytes does not apply. Legacy scripts that exceed this size are invalid regardless of their content. In Tapscript, the script can be as large as the block weight allows. The practical limit comes from the 4,000,000 weight unit block cap, which restricts total transaction size.

The Per-Input Sigops Budget

Instead of a global block-wide limit, Tapscript assigns each script-path input its own signature operations budget. The formula is:

sigops_budget = 50 + total_serialized_witness_size_in_bytes

The total serialized witness size includes the CompactSize prefix of the input's witness. Each successful signature check (by OP_CHECKSIG, OP_CHECKSIGVERIFY, or OP_CHECKSIGADD) with a non-empty signature deducts 50 from the budget. If a deduction takes the budget below zero, the script fails immediately.

Empty signatures do not consume any budget. An empty signature causes OP_CHECKSIG to push an empty vector, OP_CHECKSIGADD to push the counter unchanged, and OP_CHECKSIGVERIFY to fail immediately. This is how Tapscript handles optional signers in multisig constructions without wasting budget.

Budget Example

Consider a Tapscript input whose witness serializes to 200 bytes (including the CompactSize prefix):

Budget = 50 + 200 = 250
Each signature check costs 50
Maximum signature checks = 250 / 50 = 5

This means the input can validate up to 5 Schnorr signatures before exhausting its budget. A larger witness naturally provides a higher budget, which is self-correcting: more signatures require more witness data (public keys and signatures), which increases the budget accordingly.

Limits That Remain

Not all legacy restrictions are lifted. Two important limits still apply in Tapscript:

• MAX_SCRIPT_ELEMENT_SIZE: individual stack elements cannot exceed 520 bytes. This limits the size of any single data push onto the stack.
• The stack can hold a maximum of 1,000 elements during execution.

Why It Matters

The legacy limits were a significant bottleneck for Bitcoin Script programmability. The 201-opcode cap meant that scripts with many conditional branches (using OP_IF and related flow control) could run out of opcodes before expressing their full logic. The 10,000-byte script size cap limited how many spending paths a single output could encode.

By lifting these limits, Tapscript enables several capabilities that were previously impractical:

• Larger multisig configurations: legacy OP_CHECKMULTISIG supported at most 20 keys. Tapscript uses OP_CHECKSIGADD to build k-of-n multisig with no fixed upper bound on n, constrained only by the weight budget.
• Complex Taptree structures: with MAST-based script trees, each leaf can contain a full script. Removing the size and opcode caps means each leaf can hold more logic, and the tree can accommodate many more spending conditions.
• Advanced spending policies: protocols like Miniscript and Miniscript policies benefit from the increased script headroom, enabling more expressive wallet configurations and covenant-like constructions.

For a deeper exploration of how these changes expand what Bitcoin Script can do, see the research article on Bitcoin Script programmability and the guide to advanced Tapscript spending conditions.

Use Cases

Large Multisig and Threshold Schemes

Organizations needing 10-of-15 or even 50-of-100 multisig setups were blocked by legacy limits. Tapscript's budget model allows any number of signers, provided the transaction includes enough witness weight to cover the signature checks. Combined with MuSig2 for key aggregation or FROST for threshold signing, this opens up institutional custody and governance use cases.

Complex Conditional Vaults

Vault designs like those proposed in OP_VAULT and related covenant proposals benefit from the relaxed limits. A vault script might include multiple recovery paths, timelocked escalation, and watchtower conditions, all of which consume opcodes and script bytes. Under Tapscript, these paths can be spread across a Taptree with each leaf containing arbitrarily complex logic.

Protocol Development

Layer-2 protocols and off-chain systems that settle on Bitcoin can encode richer state transitions. The Spark protocol, for example, leverages Taproot's script-path capabilities for its on-chain settlement transactions. The relaxed budget means that more complex exit conditions and dispute resolution scripts can fit within a single Tapscript leaf.

Risks and Considerations

Weight Cost

While the opcode and script size caps are gone, the block weight limit still applies. Large scripts consume more weight, which means higher fees. A script that is technically valid under the new rules might be economically impractical to spend because the fee rate makes it too expensive.

Validation Cost

Removing the opcode count limit raises the theoretical ceiling for script complexity. While the sigops budget prevents unbounded signature checks, non-signature opcodes (like hashing operations or arithmetic) are uncapped. Future proposals such as the varops budget (BIP 440) aim to extend weight-based accounting to all variable-cost operations, not just signature checks.

Stack Limits Remain a Constraint

The 520-byte element size and 1,000-item stack limits still apply. For scripts that manipulate large data structures, these become the binding constraints rather than the opcode or size limits. Proposals to raise or remove the 520-byte limit are part of the broader script limitations discussion.

Script-Path vs. Key-Path

The budget system only applies to script-path spends. Key-path spends bypass script execution entirely, requiring only a single Schnorr signature with no sigops budget considerations. Well-designed Taproot outputs use the key path for the common case and the script path only for exceptional conditions.

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.