MegaAccessControl
MegaAccessControl system contract — proactive volatile data access restriction for call subtrees.
This page specifies the MegaAccessControl system contract. It defines the address, interface, interception semantics, and the volatile-data access restriction mechanism.
Motivation
Gas detention is reactive — it caps remaining compute gas only after volatile data has already been accessed. Contracts that call untrusted code have no way to prevent that code from silently triggering detention and tightening the caller's gas budget.
MegaAccessControl provides a proactive mechanism: a contract can disable volatile data access for its entire call subtree before any untrusted code runs. Attempts to access volatile data while disabled revert immediately, preventing both the access and the detention side effect.
Specification
Address
The MegaAccessControl system contract MUST exist at MEGA_ACCESS_CONTROL_ADDRESS.
Bytecode
The contract takes no constructor arguments. A node MUST deploy the bytecode version corresponding to the active spec.
Source: MegaAccessControl.sol
Version 1.0.0
Since: Rex4
Code hash: 0x96d0f3ba6b474e9684a97e4388ec8dbb7929818b51e6b4f19f885ccbdf642f9b
Deployed bytecode:
Interface
Interception Scope
All three functions (disableVolatileDataAccess, enableVolatileDataAccess, isVolatileDataAccessDisabled) participate in call interception. The node MUST intercept CALL and STATICCALL to MEGA_ACCESS_CONTROL_ADDRESS when the input matches a known selector.
DELEGATECALL and CALLCODE to this address MUST NOT be intercepted. They fall through to the on-chain bytecode, which reverts with NotIntercepted().
Unknown selectors MUST NOT be intercepted and MUST fall through to the on-chain bytecode.
Value Transfer Policy
All intercepted functions MUST reject calls with non-zero value transfer. If the call carries a non-zero transferred value, the node MUST revert with NonZeroTransfer().
disableVolatileDataAccess
disableVolatileDataAccessWhen intercepted, the node MUST disable volatile data access for the caller's call frame and all descendant call frames.
While disabled, any volatile data access — block environment reads, beneficiary-targeted account access (including SELFDESTRUCT to the beneficiary), and oracle storage reads — MUST revert immediately with VolatileDataAccessDisabled(VolatileDataAccessType accessType).
Blocked volatile access MUST NOT update volatile-access tracking and MUST NOT tighten gas detention.
enableVolatileDataAccess
enableVolatileDataAccessWhen intercepted, the node MUST re-enable volatile data access for the caller's call frame and descendant call frames if and only if the restriction was set at the caller's depth or was not active.
If the restriction was set by an ancestor call frame (a parent at a shallower depth), the node MUST revert with DisabledByParent().
isVolatileDataAccessDisabled
isVolatileDataAccessDisabledWhen intercepted, the node MUST return true if volatile data access is currently disabled for the caller's call frame (whether disabled by the caller or an ancestor call frame), and false otherwise.
Lifetime
The volatile data access restriction automatically ends when the call frame that called disableVolatileDataAccess returns. No explicit cleanup is needed.
Constants
MEGA_ACCESS_CONTROL_ADDRESS
0x6342000000000000000000000000000000000004
MegaAccessControl contract address
Rationale
Why a system contract instead of an EVM opcode? Volatile data access control is a MegaETH-specific mechanism with no Ethereum precedent. Using a system contract avoids polluting the opcode space and provides a stable Solidity interface that existing toolchains can use without modifications.
Why revert instead of silently blocking? Silent blocking would hide bugs. If a contract expects to read block data but the access is silently suppressed, the contract would receive stale or zero values and proceed with incorrect state. Reverting makes the restriction visible and forces the caller to handle it explicitly.
Why prevent descendant re-enabling when a parent disabled access? Allowing untrusted child code to re-enable access would defeat the purpose. The calling contract disables access precisely because it does not trust inner calls to behave correctly with volatile data. The parent-override rule preserves the caller's intent.
Spec History
Rex4 introduced the MegaAccessControl system contract.
Last updated