megaeth-labs · RealiCZ · May 7, 2026 · May 6, 2026 · May 6, 2026 · May 6, 2026
@@ -211,7 +211,7 @@ When adding a new per-frame gas mechanism, verify that all three paths handle it
 
 ## Test Organization (`crates/mega-evm/tests/`)
 
-Tests are organized by spec: `equivalence/`, `mini_rex/` (12 modules), `rex/`, `rex2/`, `rex3/`, `rex4/`, and `block_executor/`.
+Tests are organized by spec: `equivalence/`, `mini_rex/` (12 modules), `rex/`, `rex2/`, `rex3/`, `rex4/`, `rex5/`, and `block_executor/`.
 Each module tests specific features of that spec.
 
 ## Version Control

@@ -42,5 +42,5 @@ mega-evme run 0x41 --block.coinbase 0x1111111111111111111111111111111111111111
 
 The block environment affects opcodes like `NUMBER`, `TIMESTAMP`, `COINBASE`, `BASEFEE`, `DIFFICULTY` / `PREVRANDAO`, and `BLOBBASEFEE`.
 
-In MegaETH specs (MiniRex and above), accessing block environment fields triggers [gas detention](https://megaeth-labs.github.io/mega-evm/spec/evm/gas-detention.html) — the remaining compute gas is capped to reduce parallel execution conflicts.
+In MegaETH specs (MiniRex and above), accessing block environment fields triggers [gas detention](../../spec/evm/gas-detention.md) — the remaining compute gas is capped to reduce parallel execution conflicts.
 This is normal MegaETH behavior and is reflected in `mega-evme` execution.
@@ -101,4 +101,13 @@ MegaETH predeploys the following stable system contracts:
 | [MegaAccessControl](../system-contracts/mega-access-control.md)             | `0x6342000000000000000000000000000000000004` | [Rex4](../upgrades/rex4.md)       | Volatile-data access control         |
 | [MegaLimitControl](../system-contracts/mega-limit-control.md)               | `0x6342000000000000000000000000000000000005` | [Rex4](../upgrades/rex4.md)       | Query remaining compute-gas budget   |
 
+<details>
+<summary>Rex5 (unstable): SequencerRegistry</summary>
+
+| Contract                                                       | Address                                      | Since                       | Purpose                                                  |
+| -------------------------------------------------------------- | -------------------------------------------- | --------------------------- | -------------------------------------------------------- |
+| [SequencerRegistry](../system-contracts/sequencer-registry.md) | `0x6342000000000000000000000000000000000006` | [Rex5](../upgrades/rex5.md) | Dual-role registry for system address and sequencer keys |
+
+</details>
+
 For the full registry and behavioral semantics, see [System Contracts Overview](../system-contracts/overview.md).
@@ -1,6 +1,6 @@
 ---
 description: MegaETH resource accounting specification — counter semantics, revert behavior, and per-opcode metering for compute gas, data size, KV updates, and state growth.
-spec: Rex5
+spec: Rex4
 ---
 
 # Resource Accounting
@@ -110,10 +110,15 @@ The following contributions MUST be tracked within call frames and MUST be disca
 | Account update (CREATE/CREATE2)  | `ACCOUNT_UPDATE_DATA_SIZE`          | Successful account creation path         |
 | Deployed bytecode                | `code.len()`                        | Successful `CREATE` or `CREATE2`         |
 
+<details>
+<summary>Rex5 (unstable): Caller account update deduplication for data-size tracking</summary>
+
 #### Account Update Deduplication
 
 Within a single call frame, a node MUST count a given account update at most once for data-size tracking.
-If the same account is updated multiple times within the same call frame, subsequent updates in that call frame MUST NOT add additional `ACCOUNT_UPDATE_DATA_SIZE` bytes.
+If the same account is updated multiple times within the same call frame — including the caller account across multiple value-transferring sub-calls or creates — subsequent updates in that call frame MUST NOT add additional `ACCOUNT_UPDATE_DATA_SIZE` bytes.
+
+</details>
 
 ### KV Updates
 
@@ -141,11 +146,16 @@ The following contributions MUST be tracked within call frames and MUST be disca
 | CREATE/CREATE2   | `1` or `2` | Created account plus caller update if caller not yet counted in the current call frame |
 | CALL with value  | `1` or `2` | Callee update plus caller update if caller not yet counted in the current call frame   |
 
+<details>
+<summary>Rex5 (unstable): Caller account update deduplication for KV-update tracking</summary>
+
 #### Account Update Deduplication
 
 Within a single call frame, a node MUST deduplicate caller account updates for KV-update tracking in the same way it does for data-size tracking.
 When a CALL with value or CREATE occurs, the caller's update MUST be counted only if it has not already been counted in the current call frame.
 
+</details>
+
 ### State Growth
 
 #### Definition
@@ -217,4 +227,4 @@ Allowing the counter to go negative during intermediate steps keeps the accounti
 This page describes the current accounting behavior.
 
 - [Rex4](../upgrades/rex4.md) — introduced per-call-frame runtime budgets for all four resource dimensions.
-- [Rex5](../upgrades/rex5.md) — corrected caller-account update deduplication: pre-Rex5, the caller's `ACCOUNT_UPDATE_DATA_SIZE` (data size) and KV-update count were re-charged on every value-transferring sub-call or create from the same parent frame because the `target_updated` flag was never set after the first charge; Rex5 marks the flag after the first charge so subsequent operations from the same parent frame do not re-count the caller account.
+- [Rex5](../upgrades/rex5.md) (**unstable**) — corrected caller-account update deduplication: pre-Rex5, the caller's `ACCOUNT_UPDATE_DATA_SIZE` (data size) and KV-update count were re-charged on every value-transferring sub-call or create from the same parent frame because the `target_updated` flag was never set after the first charge; Rex5 marks the flag after the first charge so subsequent operations from the same parent frame do not re-count the caller account.
@@ -116,10 +116,10 @@ These are frequently accessed by many transactions and are a major source of par
 
 The effective compute gas cap imposed by [gas detention](evm/gas-detention.md).
 
-An absolute cap on total compute gas for the transaction; if the transaction has already consumed more gas than the cap when the volatile access occurs, execution halts immediately.
+A relative cap of `current_usage + cap` set at the time of volatile access; if the transaction's compute gas usage later exceeds this cap, execution halts immediately.
 
-In Rex4 and later, this is a relative cap — `current_usage + cap` at the time of volatile access.
-See the [Rex4 upgrade page](upgrades/rex4.md) for details.
+In Rex3 and earlier, this was an absolute cap on total compute gas for the transaction: if the transaction had already consumed more gas than the cap when the volatile access occurred, execution halted immediately at that point.
+The relative-cap definition above was introduced in [Rex4](upgrades/rex4.md).
 
 ## Beneficiary
 
@@ -161,7 +161,8 @@ A set of MegaETH verifiable behaviors: the complete definition of what a correct
 
 Captures the execution-layer semantics that determine node correctness.
 
-Progression: `EQUIVALENCE → MINI_REX → REX → REX1 → REX2 → REX3 → REX4`.
+Progression: `EQUIVALENCE → MINI_REX → REX → REX1 → REX2 → REX3 → REX4 → REX5`.
+REX5 is the current unstable spec under active development.
 
 See [Hardforks and Specs](hardfork-spec.md).
 
@@ -177,7 +178,7 @@ Multiple hardforks can map to the same spec (e.g., MiniRex1 → EQUIVALENCE, Min
 
 The authorized sender for [Mega System Transactions](system-contracts/system-tx.md).
 
-- Pre-[Rex5](upgrades/rex5.md): the fixed constant `0xA887dCB9D5f39Ef79272801d05Abdf707CFBbD1d` (defined in [system-tx.md § Constants](system-contracts/system-tx.md#constants)).
-- Rex5 onward: resolved per block from [`SequencerRegistry.currentSystemAddress()`](system-contracts/sequencer-registry.md).
+- The fixed constant `0xA887dCB9D5f39Ef79272801d05Abdf707CFBbD1d` (defined in [system-tx.md § Constants](system-contracts/system-tx.md#constants)).
+- _(Rex5, unstable)_ Resolved per block from [`SequencerRegistry.currentSystemAddress()`](system-contracts/sequencer-registry.md) instead of the fixed constant.
 
 Exempt from oracle [gas detention](evm/gas-detention.md); carries [Oracle](system-contracts/oracle.md) write authority.
@@ -12,8 +12,8 @@ This page defines both concepts and summarizes what each spec introduces.
 
 The protocol distinguishes between two related concepts:
 
-- **[Hardfork](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). Represented as `MegaHardfork` in the reference implementation.
-- **[Spec](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. Represented as `MegaSpecId` in the reference implementation.
+- **[Hardfork](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](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.
@@ -37,14 +37,14 @@ All other specs are stable (frozen).
 
 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: "Stable pre-{Spec} semantics MUST remain unchanged."
+Every spec carries the invariant that stable pre-{Spec} semantics remain unchanged.
 
 This means:
 
-- Contracts deployed under a given spec will continue to behave identically after future upgrades.
+- 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 MUST gate spec-specific behavior on the active spec.
+- Implementations gate spec-specific behavior on the active spec.
 
 ## Spec Summary
 
@@ -117,7 +117,10 @@ _See [Rex4 Network Upgrade](upgrades/rex4.md) for full details._
 > **Unstable** — This spec is under active development.
 > Its semantics may change before network activation.
 
-No behavioral changes have been defined yet.
-This spec serves as the placeholder for the next upgrade cycle.
+- **[SequencerRegistry](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](system-contracts/keyless-deploy.md) trailing-bytes rejection** — RLP encodings with trailing bytes after the signed payload are rejected with `MalformedEncoding()`.
 
-_See [Rex5 Network Upgrade](upgrades/rex5.md) for the latest status._
+_See [Rex5 Network Upgrade](upgrades/rex5.md) for full details._
@@ -53,7 +53,7 @@ MegaETH uses a spec system to version its verifiable behavior at each stage of t
 Each newer spec includes all previous behaviors:
 
 ```
-EQUIVALENCE → MINI_REX → REX → REX1 → REX2 → REX3 → REX4
+EQUIVALENCE → MINI_REX → REX → REX1 → REX2 → REX3 → REX4 → REX5
 ```
 
 {% hint style="info" %}
@@ -69,6 +69,7 @@ Contracts deployed under a given spec will continue to behave identically, regar
 - **REX2** — SELFDESTRUCT re-enabled (EIP-6780), KeylessDeploy system contract.
 - **REX3** — Oracle gas cap raised to 20M, SLOAD-based oracle detention, keyless deploy compute gas tracking.
 - **REX4** — Per-call-frame resource budgets, relative gas detention, [storage gas stipend](glossary.md#storage-gas-stipend), MegaAccessControl and MegaLimitControl system contracts.
+- **REX5** _(unstable)_ — SequencerRegistry system contract, Oracle v2.0.0 with dynamic system address, caller-account update deduplication, KeylessDeploy trailing-bytes rejection.
 
 See [Hardforks and Specs](hardfork-spec.md) for full details.
 

@@ -70,13 +70,20 @@ The `keylessDeploymentTransaction` argument MUST decode as a signed pre-EIP-155
 The following conditions MUST hold:
 
 - the transaction encoding is valid RLP for `TxLegacy`,
-- (Rex5+) the encoding contains no trailing bytes after the signed RLP payload,
 - the transaction is a contract creation (`to = null`),
 - the transaction has no chain ID,
 - the transaction nonce is exactly `0`.
 
 If any of those conditions fail, the call MUST revert with the corresponding validation error.
 
+<details>
+<summary>Rex5 (unstable): Trailing-bytes rejection</summary>
+
+In addition to the conditions above, the encoding MUST contain no trailing bytes after the signed RLP payload.
+If trailing bytes are present, the call MUST revert with `MalformedEncoding()`.
+
+</details>
+
 ### Validation Rules
 
 Before starting sandbox execution, the node MUST enforce the following checks:
@@ -186,3 +193,4 @@ Allowing nonce `1` preserves deployability in that case while still preventing a
 
 - [Rex2](../upgrades/rex2.md) introduced KeylessDeploy and its stable top-level interception model.
 - [Rex3](../upgrades/rex3.md) makes the overhead gas count toward compute gas accounting.
+- [Rex5](../upgrades/rex5.md) (**unstable**) rejects encodings with trailing bytes after the signed RLP payload by reverting with `MalformedEncoding()`.
@@ -27,8 +27,6 @@ The MegaAccessControl system contract MUST exist at `MEGA_ACCESS_CONTROL_ADDRESS
 The contract takes no constructor arguments.
 A node MUST deploy the bytecode version corresponding to the active spec.
 
-Source: [`MegaAccessControl.sol`](https://github.com/megaeth-labs/mega-evm/blob/main/crates/system-contracts/contracts/MegaAccessControl.sol)
-
 #### Version 1.0.0
 
 Since: [Rex4](../upgrades/rex4.md)

@@ -28,8 +28,6 @@ The MegaLimitControl system contract MUST exist at `MEGA_LIMIT_CONTROL_ADDRESS`.
 The contract takes no constructor arguments.
 A node MUST deploy the bytecode version corresponding to the active spec.
 
-Source: [`MegaLimitControl.sol`](https://github.com/megaeth-labs/mega-evm/blob/main/crates/system-contracts/contracts/MegaLimitControl.sol)
-
 #### Version 1.0.0
 
 Since: [Rex4](../upgrades/rex4.md)