Architecture
MegaETH network architecture — how transactions flow from submission through execution, streaming, and L1 settlement.
MegaETH is an Ethereum L2 built on the OP Stack, optimized for real-time execution. The sequencer produces mini-blocks every ~10 milliseconds and EVM blocks every ~1 second, streaming state to globally distributed RPC nodes so that users and applications see transaction results within milliseconds.
How a Transaction Moves Through MegaETH
Like all blockchains, MegaETH processes transactions and maintains a shared ledger. What makes it different is speed: a transaction is confirmed in roughly 10 milliseconds — not seconds or minutes. The rest of this page walks through exactly how that happens, from submission to final settlement on Ethereum L1.
1. Submission
A user's transaction — a swap, a transfer, a contract call — arrives at an RPC endpoint. The endpoint validates it (correct format, valid signature, sufficient balance) and forwards it to the sequencer, the single node responsible for ordering and executing transactions.
2. Execution
The sequencer executes the transaction against the current chain state. Every ~10 milliseconds, it seals the recently executed transactions into a mini-block — a lightweight block containing the transactions, their execution results (receipts), and the resulting state changes.
3. Streaming
The sequencer streams each mini-block to RPC nodes distributed across multiple regions. As soon as an RPC node receives a mini-block, its contents — transaction receipts, event logs, and state updates — become immediately queryable. This is how a wallet can show a confirmed transaction within milliseconds: the RPC node it connects to has already received the mini-block containing the result.
Applications that need the lowest possible latency can subscribe to mini-blocks directly via the Realtime API.
4. L1 Settlement
Periodically, the sequencer seals an EVM block — a standard Ethereum-format block that bundles all the mini-blocks produced during that interval. The block data is posted to EigenDA for data availability. EigenDA returns a certificate proving the data is available, and the OP Stack batcher submits that certificate to Ethereum L1. Block proposals can then be challenged through dispute resolution.
This is what gives MegaETH its security: even though the sequencer processes transactions at sub-second speed, all results are ultimately anchored to Ethereum and can be independently verified.
Components
Sequencer
The sequencer is the block producer — the single node that decides transaction ordering. It executes transactions, assembles them into mini-blocks and EVM blocks, and broadcasts execution results to the rest of the network.
The sequencer is operated with high availability. If the active node goes down, a standby takes over within tens of milliseconds, and software upgrades happen without pausing the chain.
RPC Nodes
RPC nodes are the network's public interface. They serve read requests (account balances, contract calls, event logs), accept transaction submissions, and maintain a replica of the chain state synced from the sequencer. Depending on how a node maintains state, there are two types:
Replica nodes receive blocks and execution results from the sequencer and apply them to a local replica of the chain's state and history without re-execution. This is the default mode — it is lightweight and optimized for serving read requests at scale.
Full nodes receive blocks and locally re-execute them, independently validating every state transition. Full nodes do not need to trust the sequencer's execution results.
MegaETH operates RPC nodes across multiple geographic regions so that users worldwide connect to a nearby node with low latency. There are two ways to access them (see Connect to MegaETH for endpoints):
Public RPC endpoint — available to everyone, rate-limited.
Managed RPC providers — Alchemy and others offer higher throughput and debug methods (
debug_*,trace_*).
Data Availability
When the sequencer produces a block, it must make the block data publicly available so that anyone can verify the chain — this is the data availability requirement. MegaETH uses EigenDA as the primary data availability layer. Without a DA certificate, the sequencer cannot submit the block to L1. This ensures that even if the sequencer behaves maliciously, replica nodes and provers can always access the data they need.
Fault Proof
MegaETH settles on Ethereum L1 using the OP Stack's dispute resolution framework. Block proposals are submitted to L1 and can be challenged within a dispute window.
For dispute resolution, MegaETH uses Kailua — a ZK fraud proof system built on RISC-Zero. Instead of the multi-round interactive bisection used by standard OP Stack, Kailua generates a single zero-knowledge proof to resolve disputes, making challenges faster and cheaper.
Provers
Provers re-execute blocks and generate cryptographic proofs that attest to the correctness of the sequencer's execution results. These proofs are used in the fault proof process: if a block proposal on L1 is challenged, a prover can produce a proof to resolve the dispute.
Related Pages
Get Started — connect your wallet, bridge ETH, and explore the network
Connect to MegaETH — chain IDs, RPC endpoints, and network parameters
Mini-Blocks — the two block types and how they enable sub-second latency
Overview — developer quickstart with RPC endpoints and chain configuration
Realtime API — subscribe to mini-blocks and get results in real time
Last updated