# 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. It is the fixed constant `0xA887dCB9D5f39Ef79272801d05Abdf707CFBbD1d` (see [Constants](#constants)).

<details>

<summary>Rex5 (unstable): Dynamic system address resolution</summary>

`MEGA_SYSTEM_ADDRESS` MUST be resolved per block from [`SequencerRegistry.currentSystemAddress()`](/spec/system-contracts/sequencer-registry.md) after all pre-block changes are committed. The fixed constant `0xA887dCB9D5f39Ef79272801d05Abdf707CFBbD1d` is replaced by this dynamic resolution; the fixed-constant rule does not apply in Rex5 and later.

</details>

### 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.

### 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.

## 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) (**unstable**) dynamized the system address: it is no longer a compile-time constant but is resolved per block from `SequencerRegistry._currentSystemAddress`. Pre-REX5 blocks continue to use the legacy `MEGA_SYSTEM_ADDRESS` constant. The system transaction identification logic and whitelist are unchanged.


---

# 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/system-contracts/system-tx.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.