VM Limits: Targeted Virtual Machine Limits

Summary

This CHIP “re-targets virtual machine (VM) limits to enable more advanced Bitcoin Cash contracts, reduce transaction sizes, and reduce full node compute requirements.” See VM limits.

Motivation

• More advanced contracts. The 201-opcode limit and the 520-byte P2SH contract limit forced authors to cut features or split logic into “harder-to-audit, multi-input systems.”
• Larger stack items. Bigger items enable post-quantum cryptography, stronger escrow and settlement strategies, larger hash preimages, zero-knowledge proofs and homomorphic encryption.
• Accurate cost accounting. The old limits were blunt: they blocked useful contracts without measuring real validation cost well.

What it specifies

• The 201-operation limit is removed, replaced by an operation cost limit of 800 per byte of “density control length” (the input’s unlocking bytecode length plus 41). Every stack push costs its length; hashing, signature checks and expensive arithmetic cost more.
• The stack element limit rises from 520 to 10,000 bytes, equal to the maximum script size.
• A hashing limit: about 3.5 digest iterations per density byte in blocks, 0.5 for standard transactions.
• A control stack limit keeps the existing maximum OP_IF/OP_NOTIF nesting depth of 100.
• The standard unlocking bytecode limit (1,650 bytes) stays unchanged, to narrow scope. The 2026 P2S CHIP later removed it.

Because every limit scales with transaction size, a larger contract gets a larger budget, yet worst-case validation cost per byte stays bounded.

Current status

Final. Activated on 15 May 2025 with BigInt. The stakeholder table records 127 approvals, 3 disapprovals (Flowee, Flowee Pay and Flowee Products) and 343 neutral; non-responses were counted as neutral.

The cost system it introduced is what made loops, functions and bitwise ops safe to add in 2026.