MegaETH RPC: A Developer's Guide (Chain ID 4326)
MegaETH is an Ethereum layer 2 built around one number: latency. Its sequencer produces "mini-blocks" roughly every 10 milliseconds and rolls them into standard EVM blocks once a second, so state changes are visible almost as soon as they execute. For RPC clients that creates two interfaces to the same chain, and a few numbers that don't match what Ethereum-trained code expects.
This guide is measured against the live chain on October 6, 2026, through the same endpoint SwiftNodes customers use.
The endpoint
https://rpc.swiftnodes.io/rpc/megaeth?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/megaeth?key=YOUR_API_KEY
import { createPublicClient, http, defineChain } from "viem";
const megaeth = defineChain({
id: 4326,
name: "MegaETH",
nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/megaeth?key=YOUR_API_KEY"] } },
});
const client = createPublicClient({ chain: megaeth, transport: http() });
What we measured
| Property | Value |
|---|---|
| Chain ID | 4326 (0x10e6) |
| EVM block time | 1.00 s (1,000-block average) |
| Gas limit | 10,000,000,000 per block |
| Base fee | 0.001 gwei |
eth_maxPriorityFeePerGas |
0 |
ETH transfer, eth_estimateGas |
63,349 |
safe lag |
~403 blocks (~7 min) |
finalized lag |
~1,937 blocks (~32 min) |
eth_getLogs |
50,000-block ranges accepted |
| Historical state | reads 10M blocks back succeeded |
trace_block, eth_getBlockReceipts |
available |
newHeads over WebSocket |
yes |
Two interfaces: EVM blocks and the realtime API
Standard JSON-RPC sees MegaETH as an ordinary EVM chain with 1-second blocks: eth_blockNumber, eth_getLogs, newHeads subscriptions and receipts all work the way they do on any OP Stack chain. That is what most indexers, wallets and dashboards need, and it is what SwiftNodes serves.
MegaETH also documents a realtime API on top: queries that read the latest mini-block instead of the latest EVM block, a miniBlocks subscription that streams the ~10 ms units, and eth_sendRawTransactionSync, which submits a transaction and waits for its receipt in the same call. Through our endpoint today:
eth_sendRawTransactionSyncworks. It replaces the usual "send, then poll for the receipt" loop with one request, which matters on a chain where the receipt exists a few milliseconds after the send.- The
miniBlockssubscription does not. Our WebSocket layer currently refuses non-standard subscription types;newHeadsandlogsare fine.
If your application needs mini-block granularity (trading, games, anything reacting inside a second), check that your provider exposes the realtime methods specifically, not just "MegaETH RPC".
Gotcha 1: a transfer is not 21,000 gas
Code that hardcodes gas: 21000n for ETH transfers fails or underpays on MegaETH. eth_estimateGas for a plain transfer returned 63,349 on our endpoint. Let the node estimate:
const gas = await client.estimateGas({ account, to, value });
The same rule applies to any precomputed gas constant carried over from Ethereum. Our guide to estimating gas with eth_estimateGas covers the general pattern.
Gotcha 2: the block gas limit is enormous
Each block allows 10 billion gas, thousands of times Ethereum's limit. Two consequences:
- Don't size anything off the block gas limit. Libraries that cap a transaction's gas at "block gas limit minus a margin" will happily produce absurd numbers.
gasUsedRatiofrometh_feeHistorylooks tiny and flat (we saw 0.1 for every block), because almost no block fills. It says little about congestion.
Gotcha 3: eth_feeHistory's oldestBlock is wrong
Asking eth_feeHistory for the last five blocks at latest returned oldestBlock: 0xffffc (block 1,048,572), millions of blocks behind the actual head. The fee values themselves were consistent (a flat 0.001 gwei base fee), so use them, but don't use oldestBlock to label which blocks they belong to. Take block numbers from eth_blockNumber instead. Live fees are on our MegaETH gas tracker.
Logs and history
eth_getLogs accepted every range we tried up to 50,000 blocks (about 14 hours of chain time), and historical state reads ten million blocks back succeeded. Because blocks come every second, a day of chain is 86,400 blocks: two 50,000-block pages. Method-by-method support is on the eth_getLogs on MegaETH page, and our survey of getLogs range caps shows how unusual 50,000 is.
Finality
safe trails the head by about 7 minutes and finalized by about 32 minutes. Mini-block speed is about visibility, not settlement: a transaction confirmed in 10 ms is a sequencer promise until the batch is posted and Ethereum finalizes it. Use latest for UX and safe or finalized for anything that moves money; see soft vs hard finality on L2s.
Summary
- 1 s EVM blocks over ~10 ms mini-blocks; standard RPC sees the 1 s view.
eth_sendRawTransactionSyncworks through SwiftNodes;miniBlockssubscriptions don't yet.- Estimate gas: a transfer measured 63,349, not 21,000.
- Ignore
eth_feeHistory'soldestBlock; the fee values are fine. - 50,000-block log ranges and deep history work;
finalizedis ~32 minutes behind.
MegaETH endpoints and live status are on our MegaETH RPC page, alongside 127 other chains on one key. SwiftNodes has a free tier to try it.
John Sullivan covers RPC infrastructure, node operations, and multi-chain development at SwiftNodes — what it actually takes to keep endpoints fast, fresh, and reliable across EVM and non-EVM networks.
Related posts
- Abstract RPC: A Developer's Guide (Chain ID 2741)
Abstract is a ZK Stack rollup where most transactions come from smart accounts. Measured: 0.58 s blocks, a flat 0.045 gwei gas price, transfers using ~95k gas, a 10,000-log result cap, ~3.8 h to finalized, and full history from block 1.
- Ronin RPC After the Move to Ethereum L2: A Developer's Guide (Chain ID 2020)
Ronin became an OP Stack layer 2 in May 2026. Measured: 2 s blocks, a fixed 20 gwei base fee, a 200-block getLogs cap, ~23 min to finalized, and no pre-migration history.
- opBNB RPC: A Developer's Guide (Chain ID 204)
opBNB is an OP Stack L2 settling to BNB Smart Chain, with 250 ms blocks. Measured finality, fees, the 50,000-block getLogs cap and a stale-finality trap.