MegaETH RPC: A Developer's Guide (Chain ID 4326)

By John Sullivan · October 6, 2026 · 4 min read · #megaeth #megaeth rpc #layer 2 #real-time #developer guide

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_sendRawTransactionSync works. 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 miniBlocks subscription does not. Our WebSocket layer currently refuses non-standard subscription types; newHeads and logs are 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.
  • gasUsedRatio from eth_feeHistory looks 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_sendRawTransactionSync works through SwiftNodes; miniBlocks subscriptions don't yet.
  • Estimate gas: a transfer measured 63,349, not 21,000.
  • Ignore eth_feeHistory's oldestBlock; the fee values are fine.
  • 50,000-block log ranges and deep history work; finalized is ~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.

J
John Sullivan
Infrastructure Writer, SwiftNodes

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

Try SwiftNodes free — multi-chain RPC across 83 networks, flat-rate pricing, pay by card or crypto, no KYC. Get an API key in 30 seconds →