> For the complete documentation index, see [llms.txt](https://docs.megaeth.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.megaeth.com/spec/system-contracts/system-tx.md).

# Mega System Transactions

This page specifies how MegaETH identifies and processes Mega System Transactions. These transactions provide protocol-level maintenance access to whitelisted system contracts.

## Motivation

MegaETH needs a protocol-native mechanism for protocol-managed maintenance operations such as updating Oracle state. Those operations must execute with special fee and validation semantics while remaining part of the verifiable execution model.

Mega System Transactions provide that mechanism.

## Specification

### Resolution

`MEGA_SYSTEM_ADDRESS` is the authorized system-transaction sender for the current block. A node MUST resolve it per block from [`SequencerRegistry.currentSystemAddress()`](/spec/system-contracts/sequencer-registry.md) after all pre-block changes are committed. The fixed constant `0xA887dCB9D5f39Ef79272801d05Abdf707CFBbD1d` is the genesis seed value for this address (see [Constants](#constants)); subsequent rotations are reflected by the registry value.

### Identification

A transaction MUST be classified as a Mega System Transaction if and only if all of the following are true:

1. the transaction type is legacy (`0x0`),
2. the signer is `MEGA_SYSTEM_ADDRESS`,
3. the transaction target is a `CALL` to an address in `MEGA_SYSTEM_TX_WHITELIST`.

CREATE transactions from `MEGA_SYSTEM_ADDRESS` MUST NOT be treated as Mega System Transactions.

### Stable Whitelist

`MEGA_SYSTEM_TX_WHITELIST` MUST contain only `ORACLE_CONTRACT_ADDRESS`.

### Processing Semantics

When a transaction is classified as a Mega System Transaction, a node MUST process it with the following special semantics:

* It MUST bypass ordinary signature validation.
* It MUST bypass gas-fee charging.
* It MUST bypass nonce validation.
* It MUST bypass balance checks for gas fees.
* It MUST preserve `MEGA_SYSTEM_ADDRESS` as the caller seen by the target contract.

Although nonce validation is bypassed, the sender nonce MUST still increment after execution.

Mega System Transactions MUST NOT cause state changes to the block beneficiary or fee vaults.

Before applying the special semantics above, a node MUST validate the transaction's chain id, nonce, and sender-code status against the same canonical rules that ordinary transactions follow:

* The transaction's chain id MUST be present and MUST equal the node's configured chain id, unless the chain-id check is disabled by node configuration.
* The transaction's nonce MUST equal the current account nonce of `MEGA_SYSTEM_ADDRESS`, unless the nonce check is disabled by node configuration.
* If `MEGA_SYSTEM_ADDRESS` carries code, the EIP-3607 sender-has-code rule applies, unless EIP-3607 enforcement is disabled by node configuration.

A transaction failing any of these checks MUST be rejected with the corresponding canonical invalid-transaction error (missing chain id, invalid chain id, nonce too low, nonce too high, or caller-has-code rejection) before any state mutation, signature bypass, or fee bypass takes effect. The remaining bypasses (signature, gas-fee charging, balance) MUST still apply once these checks pass.

<details>

<summary>Rex6 (unstable): System-originated transaction metering exemption</summary>

#### System-Originated Transaction Metering Exemption

A transaction is **system-originated** when either:

* its caller is the [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935) / [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) system address `0xfffffffffffffffffffffffffffffffffffffffe`, which is how the protocol issues its pre-block system calls (block-hash and beacon-root updates, and `SequencerRegistry.applyPendingChanges()`); or
* it is a Mega System Transaction, recognized both before and after its deposit promotion.

Ordinary user transactions — including user deposit transactions — are never system-originated.

Under Rex6, a node MUST exempt a system-originated transaction from MegaETH's per-transaction resource metering:

* Dynamic storage gas MUST be charged at the [minimum bucket capacity](/spec/megaevm/dual-gas-model.md#dynamic-salt-multiplier) (`multiplier = 1`), so the cost does not depend on actual SALT bucket capacity.
* The four [runtime transaction-level resource limits](/spec/megaevm/resource-limits.md#runtime-transaction-level-limits) (compute gas, data size, KV updates, state growth) MUST NOT halt the transaction.
* The [gas detention](/spec/megaevm/gas-detention.md) compute-gas cap MUST NOT halt the transaction.
* Resource usage MUST still be recorded; only the per-transaction halt decision is suppressed.

The transaction's standard EVM `gas_limit` — for the pre-block system calls, floored at `SYSTEM_CALL_GAS_LIMIT_FLOOR` (30,000,000) — remains the only bound that can halt a system-originated transaction.

Pre-Rex6 specs meter every transaction, including the protocol's own, identically to user transactions.

</details>

### Scope

This page specifies the execution semantics of Mega System Transactions. Admission policy — including which external actor is allowed to inject such transactions into the chain — is outside the scope of this specification.

## Constants

| Constant                   | Value                                        | Description                                          |
| -------------------------- | -------------------------------------------- | ---------------------------------------------------- |
| `MEGA_SYSTEM_ADDRESS`      | `0xA887dCB9D5f39Ef79272801d05Abdf707CFBbD1d` | Special maintenance sender address                   |
| `MEGA_SYSTEM_TX_WHITELIST` | `{ ORACLE_CONTRACT_ADDRESS }`                | Stable whitelist of callable system-contract targets |

## Rationale

**Why special transaction semantics instead of ordinary calls?** Protocol maintenance operations such as Oracle updates must execute with deterministic behavior that is not coupled to ordinary fee payment and admission semantics. Giving them distinct execution treatment makes that behavior explicit.

**Why preserve the caller as `MEGA_SYSTEM_ADDRESS`?** Whitelisted target contracts must be able to distinguish protocol-maintenance calls from ordinary user calls. Preserving the caller identity provides that signal without introducing a separate call context type.

**Why restore the chain-id, nonce, and EIP-3607 checks?** Earlier specs bypassed all four canonical pre-checks via OP-style deposit promotion. OP deposits can do this because L1 derivation and per-deposit source-hash uniqueness provide replay protection at a higher layer. MegaETH system transactions have neither, so the canonical chain-id, nonce, and sender-code checks are restored to guard against replay and cross-chain misuse. The configuration toggles for these checks are honored so that the system-transaction validation path stays symmetric with the ordinary user-transaction validation path for debugging, state-test, and replay tooling.

## Security Considerations

**The no-fee/no-nonce exemption MUST apply exclusively to addresses in `MEGA_SYSTEM_TX_WHITELIST`.** If the whitelist check were absent or misconfigured, any legacy transaction from `MEGA_SYSTEM_ADDRESS` could bypass gas fees and nonce validation for arbitrary targets, enabling cost-free state manipulation across the entire chain.

**Adding an address to `MEGA_SYSTEM_TX_WHITELIST` is a consensus-critical change.** Any modification to the stable whitelist changes which transactions receive privileged processing. Such changes MUST be gated by a spec upgrade to ensure all nodes agree on the new whitelist contents at the same activation point.

**CREATE transactions from `MEGA_SYSTEM_ADDRESS` MUST NOT receive privileged processing.** Allowing fee-exempt contract creation would let `MEGA_SYSTEM_ADDRESS` deploy arbitrary code at no cost, which is outside the intended maintenance scope.

## Spec History

* [MiniRex](/spec/network-upgrades/minirex.md) introduced Mega System Transactions and the `MEGA_SYSTEM_ADDRESS` mechanism.
* [Rex](/spec/network-upgrades/rex.md), [Rex1](/spec/network-upgrades/rex1.md), [Rex2](/spec/network-upgrades/rex2.md), and [Rex3](/spec/network-upgrades/rex3.md) retain the same stable semantics.
* [Rex5](/spec/network-upgrades/rex5.md) dynamized the system address — it is no longer a compile-time constant but is resolved per block from `SequencerRegistry.currentSystemAddress()` — and restored the canonical chain-id, nonce, and EIP-3607 sender-code checks that earlier specs bypassed via deposit promotion. Blocks before Rex5 continue to use the legacy `MEGA_SYSTEM_ADDRESS` constant and the deposit-promotion bypasses. The system transaction identification logic and whitelist are unchanged.
* Rex6 (**unstable**) — exempts system-originated transactions (pre-block system calls and Mega System Transactions) from per-transaction resource metering: dynamic storage gas is charged at minimum bucket capacity, and the four resource-limit dimensions plus gas detention no longer halt them; usage is still recorded and the standard `gas_limit` remains the only halting bound.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.megaeth.com/spec/system-contracts/system-tx.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.