MegaETH Documentation

website·Indexed 30 days ago

https://megaeth-docs.vercel.app

Documentation for MegaETH, featuring the MOSS wallet and SDKs. Includes technical specifications for MegaEVM, such as the dual-gas model and system contracts for high-precision timestamps and keyless deployment. Provides developer guides for the MOSS React SDK, Core SDK, and CLI, covering wallet methods for transfers, swaps, and signing, as well as AI agent integration and UX best practices.

Tokens
35.2K
Snippets
147
Records
376
Agent score
75%

What's inside MegaETH

  1. Overview of mega-evme CLI tool

    mega-evme is a command-line tool for executing and debugging EVM bytecode on MegaETH specifications. It allows full control over the execution environment, specifically supporting MegaETH features such as SALT bucket configuration, multidimensional resource limits, and gas detention.
  2. Overview of MegaETH Realtime API capabilities

    The Realtime API is designed to replace polling-heavy flows with subscription-native UX. Compared to standard RPC, it provides near-immediate receipt paths, push-based state streams via eth_subscribe, and latency profiles bound by mini-blocks rather than full blocks.
  3. Overview of Rex6 network upgrade changes

    The Rex6 specification introduces fourteen changes to gas metering, resource accounting, execution behavior, and system contracts. Most changes are consensus-visible, with the exception of the CREATE-family early-halt ordering (trace-visible only) and the KeylessDeploy occupancy read (affects transaction read set only). Key updates include:

    • Unified Gas Metering: Establishes a canonical order for storage-affecting opcodes to charge storage gas and record compute gas, including CREATE2.
    • EIP-7702 Authorization: Consolidates authorization accounting via a single applied-authorization scan during transaction validation.
    • CREATE-frame Accounting: Corrects creator nonce-bump and net-new state-growth accounting for the CREATE frame.
    • KeylessDeploy Hardening: Rescues unused gas for the outer sender if a dispatch hits the compute-gas limit; reports constructors that self-destruct as empty-code deployments.
    • Fee-Reward Accounting: Includes account writes from the post-execution beneficiary fee-reward step in resource accounting.
    • System Transaction Exemption: Exempts protocol-originated transactions from per-transaction resource metering to ensure protocol-mandated state changes are not pushed out of gas as SALT buckets grow.
  4. Overview of MegaETH High-Performance L2

    MegaETH is a high-performance Ethereum Layer 2 (L2) solution designed for real-time transaction processing, achieving block times of approximately 10ms.
  5. Overview of MegaETH JSON-RPC Interface

    MegaETH provides an Ethereum-compatible JSON-RPC interface accessible via HTTP and WebSocket. While it maintains compatibility with Ethereum standards, it includes additional methods and real-time behaviors specific to the MegaETH network.
  6. Overview of the SequencerRegistry system contract

    The SequencerRegistry is a system contract in MegaETH that tracks and decouples two independent roles: the system address (used by the Oracle and system-transaction authority) and the sequencer (the mini-block signing key). By decoupling these roles, MegaETH allows each to be updated independently without requiring contract redeployment. The registry enables on-chain verification of mini-block signatures and provides a dynamic Oracle authority, replacing the need for a hardcoded MEGA_SYSTEM_ADDRESS.
  7. Overview of MegaETH debug-trace-server

    The debug-trace-server provides debug_* and trace_* JSON-RPC methods for MegaETH. Unlike traditional trace servers, it re-executes blocks against SALT witness data rather than a full state database. This allows it to run on commodity hardware without requiring a full archive node. It can trace any block or transaction served by the MegaETH RPC endpoint it is pointed at.
  8. Overview of the MegaETH Oracle system contract

    The Oracle system contract serves as the canonical protocol-level storage backend for externally sourced data, such as timestamps and other oracle-fed values. It is designed to be readable by smart contracts and writable only by protocol-controlled maintenance transactions to ensure stability across specifications.
  9. Overview of MegaETH Verifiable Behavior and Specification

    MegaETH is a high-performance blockchain designed for sub-millisecond block times and high transaction gas limits. Its verifiable behavior is defined by a formal specification that ensures any node implementation producing the same outputs for the same inputs is correct. MegaETH inherits standard EVM semantics from Optimism Isthmus (Ethereum Prague) unless explicitly overridden. Transactions that do not interact with MegaETH-specific features behave identically to Optimism.
  10. Understand MegaETH Architecture and Mini-Blocks

    MegaETH utilizes a redesigned block format to achieve real-time performance. Key conceptual areas include:

    • Architecture: The flow of transactions from submission through execution, streaming, and L1 settlement.
    • Mini-Blocks: The implementation of two distinct block types to optimize performance.
  11. Understand the MegaETH stateless validator

    The stateless validator is a Rust-based client used to independently verify MegaETH blocks without maintaining a full local chain state. It works by re-executing each block against a compact cryptographic witness (provided by the network) and verifying that the resulting post-state matches the commitments in the block header. This allows for real-time verification of the MegaETH Mainnet on commodity hardware (e.g., a laptop).
  12. Understand the MiniRex Dual Gas Model

    MiniRex introduces a dual gas model that separates compute gas from storage gas. This allows independent pricing of computational work versus persistent storage burden, preventing storage operations from becoming underpriced due to MegaETH's low base fees and high gas limits. In this model, a transaction's total gas cost is the sum of its compute gas (standard EVM opcode costs) and its storage gas (charges for operations imposing persistent storage burden).