# Hardforks and Specs

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**](/spec/reference/glossary.md#hardfork-megahardfork) — 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**](/spec/reference/glossary.md#spec-megaspecid) — 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. REX5 is currently **unstable** — its semantics can still change before network activation. All other specs are stable (frozen).

### Backward Compatibility

EVM semantics for stable (activated) specs are frozen. A new spec may add behavior or change the unstable spec, 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**](/spec/megaevm/dual-gas-model.md) — [Compute gas](/spec/reference/glossary.md#compute-gas) + [storage gas](/spec/reference/glossary.md#storage-gas)
* [**Multidimensional resource limits**](/spec/megaevm/resource-limits.md) — Compute gas (1B), data size (3.125 MB), KV updates (125K)
* [**Dynamic gas costs**](/spec/megaevm/dual-gas-model.md#dynamic-salt-multiplier) — [SALT bucket](/spec/reference/glossary.md#salt-bucket)-based scaling
* [**Gas detention**](/spec/megaevm/gas-detention.md) — [Volatile data](/spec/reference/glossary.md#volatile-data) access triggers gas limiting
* **SELFDESTRUCT disabled**
* **Large contract support** — 512 KB contracts (21x increase from 24 KB)

*See* [*MiniRex Network Upgrade*](/spec/network-upgrades/minirex.md) *for full details.*

### REX

Refines the [storage gas](/spec/reference/glossary.md#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](/spec/reference/glossary.md#salt-bucket) charge 0 storage gas
* **Security fixes** — DELEGATECALL, STATICCALL, CALLCODE properly enforce gas forwarding and oracle access detection
* [**State growth**](/spec/megaevm/resource-accounting.md#state-growth) **tracking** — New [resource limit](/spec/megaevm/resource-limits.md) dimension

*See* [*Rex Network Upgrade*](/spec/network-upgrades/rex.md) *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*](/spec/network-upgrades/rex1.md) *for full details.*

### REX2

* **SELFDESTRUCT restored** — Re-enabled with [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780) semantics
* [**KeylessDeploy**](/spec/system-contracts/keyless-deploy.md) **system contract** — Enables deterministic cross-chain deployment (Nick's Method)

*See* [*Rex2 Network Upgrade*](/spec/network-upgrades/rex2.md) *for full details.*

### REX3

* **Increased oracle access gas limit** — Raised from 1M to 20M
* **SLOAD-based** [**oracle**](/spec/system-contracts/oracle.md) **detention** — Triggers on SLOAD from oracle storage instead of CALL to oracle contract
* [**Keyless deploy**](/spec/system-contracts/keyless-deploy.md) [**compute gas**](/spec/reference/glossary.md#compute-gas) **tracking** — Records the 100K overhead as compute gas

*See* [*Rex3 Network Upgrade*](/spec/network-upgrades/rex3.md) *for full details.*

### REX4

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

*See* [*Rex4 Network Upgrade*](/spec/network-upgrades/rex4.md) *for full details.*

### REX5

> **Unstable** — This spec is under active development. Its semantics may change before network activation.

* [**SequencerRegistry**](/spec/system-contracts/sequencer-registry.md) **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**](/spec/system-contracts/keyless-deploy.md) **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.

*See* [*Rex5 Network Upgrade*](/spec/network-upgrades/rex5.md) *for full details.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.megaeth.com/spec/hardfork-spec.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.