Hardforks and Specs

MegaETH hardfork and spec versioning — how behavioral changes are versioned, activated, and tracked across network upgrades.

MegaETH versions its verifiable behavior through hardforks and specs. This page defines both concepts and summarizes what each spec introduces.

Hardfork vs Spec

The protocol distinguishes between two related concepts:

• Hardfork — A network upgrade event: when changes are activated on the chain. A hardfork may include protocol-level changes beyond MegaEVM (e.g., networking, state sync, RPC behavior).
• Spec — A set of MegaETH verifiable behaviors: what a correct node does. A spec captures the execution-layer semantics that determine node correctness.

Multiple hardforks can map to the same spec. A hardfork can also map to an older spec. For example: MiniRex → MINI_REX, MiniRex1 → EQUIVALENCE (rollback), MiniRex2 → MINI_REX (restoration).

This documentation covers specs — the verifiable behavioral definitions that determine correctness of a MegaETH node. Protocol-level changes outside the verifiable execution layer (e.g., networking, peer discovery) that are part of a hardfork are not covered here.

Spec Progression

EQUIVALENCE → MINI_REX → REX → REX1 → REX2 → REX3 → REX4 → REX5

Each newer spec includes all previous behaviors. All specs build on Optimism Isthmus (Ethereum Prague) as the base layer. All specs are stable (frozen).

Backward Compatibility

EVM semantics for stable (activated) specs are frozen. A new spec may add behavior, but it never alters what an existing stable spec does. Every spec carries the invariant that stable pre-{Spec} semantics remain unchanged.

This means:

• Contracts deployed under a given spec continue to behave identically after future upgrades.
• Adding or modifying a system contract requires introducing a new spec.
• Changing gas costs, opcode behavior, or resource limits requires a new spec.
• Implementations gate spec-specific behavior on the active spec.

Spec Summary

EQUIVALENCE

The baseline spec. Maintains full compatibility with Optimism Isthmus EVM. Adds block environment access tracking for parallel execution support.

MINI_REX

The first spec to introduce MegaETH-specific modifications:

• Dual gas model — Compute gas + storage gas
• Multidimensional resource limits — Compute gas (1B), data size (3.125 MB), KV updates (125K)
• Dynamic gas costs — SALT bucket-based scaling
• Gas detention — Volatile data access triggers gas limiting
• SELFDESTRUCT disabled
• Large contract support — 512 KB contracts (21x increase from 24 KB)

See MiniRex Network Upgrade for full details.

REX

Refines the storage gas economics introduced in MINI_REX:

• Refined storage gas formulas — Gradual scaling (20K–32K base costs vs MiniRex's 2M)
• Transaction intrinsic storage gas — 39,000 flat fee for all transactions
• Zero cost fresh storage — Minimum-sized SALT buckets charge 0 storage gas
• Security fixes — DELEGATECALL, STATICCALL, CALLCODE properly enforce gas forwarding and oracle access detection
• State growth tracking — New resource limit dimension

See Rex Network Upgrade for full details.

REX1

• Limit reset fix — Resets compute gas limits at the start of each transaction
• Inherits Rex semantics fully

See Rex1 Network Upgrade for full details.

REX2

• SELFDESTRUCT restored — Re-enabled with EIP-6780 semantics
• KeylessDeploy system contract — Enables deterministic cross-chain deployment (Nick's Method)

See Rex2 Network Upgrade for full details.

REX3

• Increased oracle access gas limit — Raised from 1M to 20M
• SLOAD-based oracle detention — Triggers on SLOAD from oracle storage instead of CALL to oracle contract
• Keyless deploy compute gas tracking — Records the 100K overhead as compute gas

See Rex3 Network Upgrade for full details.

REX4

• Per-call-frame resource budgets — All four resource dimensions (compute gas, data size, KV updates, state growth) are bounded per call frame with 98/100 forwarding
• Relative gas detention cap — Effective detained limit is current_usage + cap instead of an absolute cap
• Storage gas stipend — Value-transferring CALL/CALLCODE receives an additional 23,000 gas for storage gas operations, fixing LOG events in receive() under the dual gas model
• MegaAccessControl system contract — Allows contracts to proactively disable volatile data access for a call subtree
• MegaLimitControl system contract — Allows querying effective remaining compute gas under detention and call frame limits
• Keyless deploy sandbox environment inheritance — Sandbox inherits parent transaction's external environment for dynamic pricing and oracle behavior

See Rex4 Network Upgrade for full details.

REX5

• SequencerRegistry system contract — Tracks the system address and sequencer roles independently with on-chain change scheduling and history.
• Dynamic system address — MEGA_SYSTEM_ADDRESS is resolved per block from SequencerRegistry.currentSystemAddress() instead of a hardcoded constant.
• Oracle v2.0.0 — onlySystemAddress reads the authority from SequencerRegistry. In-place Oracle bytecode upgrades preserve existing storage instead of clearing it.
• Caller-account update deduplication — Fixes overcounting of caller-account data-size and KV updates across multiple value-transferring sub-calls or creates from the same parent frame.
• KeylessDeploy trailing-bytes rejection — RLP encodings with trailing bytes after the signed payload are rejected with MalformedEncoding().
• CALLCODE new-account storage gas fix — New-account storage gas is now charged against the caller's storage context rather than the code-source address.
• Storage-gas-stipend separated allowance — The STORAGE_CALL_STIPEND no longer inflates the callee's gas limit; it is a per-frame allowance drawn only at storage-gas surcharge sites and is neither burned nor rescued.
• Value-transfer CALL/CALLCODE compute attribution — Compute gas recorded into the parent excludes the CALL_STIPEND granted to the callee.
• CREATE code-deposit compute-gas atomicity — Contract-creation code-deposit compute gas is charged atomically with the deployment commit and not double-counted in post-execution accounting.
• EIP-2935 / EIP-4788 pre-block gas floor — The history-storage and beacon-roots pre-block system calls use max(block_gas_limit, 30,000,000) and are fail-closed: a non-successful call rejects the block.
• CREATE2 empty-initcode short-circuit — A CREATE2 with zero-length init code short-circuits after the salt check using the empty-code hash, without offset conversion, memory expansion, or hashing.
• KeylessDeploy empty-code log forwarding — An empty-runtime-code deployment success forwards the constructor's logs before returning.

See Rex5 Network Upgrade for full details.