MegaETH's Ten Milliseconds, Measured from London

Drafted January 2026. Finished and published August 2026 as part of the migration away from WordPress.

MegaETH markets itself as the first real-time blockchain: the sequencer executes transactions as they arrive and streams the results in mini blocks roughly every ten milliseconds. This month I put a stopwatch on that figure from London while evaluating MegaETH against Base for a product whose users transact through embedded browser wallets.

Under conditions tuned to give the chain every advantage, submitting a transaction and getting the receipt back averaged 435 milliseconds in the best run. The fastest single call was 324. The same test on Base averaged 422. Those are good numbers. They are also more than forty times the advertised figure, and statistically indistinguishable from Base.

The ten milliseconds is not a lie. It is a real property of the sequencer, measured under conditions that are not an application signing through a wallet provider from a user’s device. This note is about where the gap goes.

What the headline figure depends on

The advertised number rests on a specific interface. MegaETH’s real-time path, realtime_sendRawTransaction, submits a transaction and returns the receipt in the same call. The standard RPC does not behave like that: on the testnet, receipts came back on roughly a one-second cadence and the real-time endpoint was not available. A meaningful measurement has to go through the real-time path, so that is what I benchmarked once I had mainnet access.

The chain by itself

To isolate the chain I stripped the test to a plain TypeScript script: no frontend, no wallet provider, local signing, nonce and gas prepared before the clock started, connections warmed, identical conditions on both networks. A real user never sees conditions this favourable.

Every number below ran over each chain’s public endpoints. I used wss://mainnet.megaeth.com/ws for MegaETH’s real-time submission, https://mainnet.megaeth.com/rpc for its ordinary RPC calls, and https://mainnet-preconf.base.org for Base Flashblocks.

The test transaction was a simple ETH transfer back to the sending wallet. Reduced to the part being measured, the harness looked like this:

const megaeth = new ethers.WebSocketProvider(
  "wss://mainnet.megaeth.com/ws"
);
const base = new ethers.JsonRpcProvider(
  "https://mainnet-preconf.base.org"
);

// Connections, nonces and fixed gas values were prepared first.
const megaethRawTx = await wallet.signTransaction(megaethTransfer);
const baseRawTx = await wallet.signTransaction(baseTransfer);

const megaethStarted = performance.now();
const megaethReceipt = await megaeth.send(
  "realtime_sendRawTransaction",
  [megaethRawTx]
);
const megaethMs = performance.now() - megaethStarted;

const baseStarted = performance.now();
const baseHash = await base.send("eth_sendRawTransaction", [baseRawTx]);
const baseSubmitMs = performance.now() - baseStarted;
const baseReceipt = await base.waitForTransaction(baseHash);
const baseReceiptMs = performance.now() - baseStarted;

Signing, nonce lookup and gas preparation all happened before these timers started. For MegaETH, the timed call returned the receipt. For Base, I recorded both the time to receive the transaction hash and the total time until the receipt arrived.

Path timed	Advertised	Fastest	Average	p95
MegaETH, realtime_sendRawTransaction (submit and receipt in one call)	~10ms	324ms	435ms	697ms
Base, eth_sendRawTransaction (submit only)	~200ms	98ms	115ms	300ms
Base, submit plus receipt		304ms	422ms	577ms

Best case measured from London, January 2026. The MegaETH call includes the receipt, so its fair comparison is the Base submit-plus-receipt row.

Base’s advertised figure held. Flashblocks are designed around 200 milliseconds and submission averaged 115. MegaETH’s did not: nothing produced a number within an order of magnitude of ten milliseconds, and its timings varied more than Base’s on every run.

The same window supplied a reliability picture for free. Alchemy’s MegaETH WebSocket endpoint stopped delivering new block headers to our backend.

The backend expected a new block at least once every ten seconds. If none arrived, its process manager restarted the worker and established a new connection. That recovery behaviour belonged to our application, not the RPC. During this incident it did not help: every new connection received the same stale head and then timed out again.

There was a separate mainnet nonce problem. A private MegaETH HTTPS endpoint returned account state which caused the test transaction to fail with Nonce gap too high for low balance account. Gap: 40. Sending the transaction through https://mainnet.megaeth.com/rpc made it work, after which the private endpoint also started responding correctly.

This had happened before on MegaETH Testnet V2. I first reported the stale nonce on 27 November 2025: the block explorer showed one transaction for the address, while the RPC returned a nonce of zero. I had tried both Alchemy and the public RPC. MegaETH then provided a private endpoint, but the issue was still present on 2 December. On 12 December, both that private endpoint and Alchemy returned zero. Unlike the mainnet incident, it had not resolved when I last tested it.

Five locations

Two days later I ran the same submit-plus-receipt comparison from five vantage points.

Location	MegaETH	Base
London, direct	641ms	339ms
London, via VPN	1,062ms	375ms
New York, via VPN	806ms	339ms
Kuala Lumpur, via VPN	527ms	2,148ms
North Virginia, AWS host	433ms	74ms

Same script, same conditions, submit plus receipt on both chains. The VPN rows carry VPN routing overhead, so compare them against each other rather than against the direct rows.

Base was faster from every location except Kuala Lumpur, where MegaETH was four times faster. That pattern reads as geography: distance to the sequencer dominates, with London near the far end of the world for MegaETH and close for Base. From London it takes around ten milliseconds just to ping an ordinary URL.

On 20 January I ran a final 20-iteration comparison from London because I was concerned that the earlier self-transfer test was too artificial. With transactions signed locally, MegaETH averaged 397 milliseconds from signing to receipt, against 462 milliseconds for Base. Their fastest results were almost identical at 310 and 309 milliseconds. This run put MegaETH slightly ahead, while the earlier London run put Base slightly ahead, reinforcing that neither network had a consistent user-visible advantage.

The rest of the path

The controlled numbers above are the best case. The path a user feels started somewhere else entirely.

The first stopwatch on the production-shaped path, a transaction signed and submitted through Privy’s hosted wallet API with the frontend polling for a receipt, read about seven seconds per transaction. None of that was the chain, and it is roughly 700 times the advertised figure.

First tests through Privy embedded wallets came in at 800 to 1,200 milliseconds per transaction. The round trip through Privy’s hosted API to sign and submit took 800 to 1,000 milliseconds on its own. Fetching the receipt took 35.

Two changes fix most of it, and both measured out. realtime_sendRawTransaction returns the receipt in the same call, which removes the polling. And signing can move on-device, which Privy supports as an advanced configuration on request. Signing through Privy’s hosted environment measured 163 to 284 milliseconds across repeated runs, averaging 191. A raw local key signed the same transaction in 11. One caveat: wallets created in the hosted environment are pinned to it, so moving to on-device signing means regenerating the wallets.

Smart-wallet paths with gas sponsorship, which route through a bundler and wait on a user-operation receipt, added whole seconds in tests earlier this month.

The chain was never the bottleneck

Seven seconds of latency was receipt polling and a hosted signing API. Eight hundred milliseconds was a REST call to a wallet provider. Moving signing on-device took that step from roughly 200 milliseconds to tens. Every one of those wins came from the application’s own stack, none required changing chain, and the largest of them is bigger than the entire measured difference between the two chains.

If the end-to-end path is hundreds of milliseconds of wallet and network overhead, the difference between the chains is not what users feel.

Why we stayed on Base

By the end of the testing, we had decided not to use MegaETH for this release. The isolated latency result was only part of that decision. We did not think the network and its supporting RPC infrastructure were production-ready for our product at that point.

The MegaETH team replied to our reports and asked for reproduction details, but we did not receive a confirmed cause or durable resolution for the stale nonces or the block-subscription failure within our decision window. From our side, the issues remained open. An RPC failure would have made most of the application unavailable and could have left users unable to manage active financial positions, so reliability carried more weight than a small latency improvement.

Once the complete transaction path was included, MegaETH was not consistently faster than Base. Base was already a mature network which we understood operationally. Faced with similar user-visible performance and very different infrastructure risk, we chose to launch on Base.

The rule

Measure the thing you are optimising, on your own workload, from where your users are, before committing to a decision that depends on it. The entire rig here was a small TypeScript script. An advertised latency figure is a benchmark of something, under someone else’s conditions. Until it has been reproduced on your own path, treat it as a hypothesis.

None of this is a complaint about MegaETH. The ten milliseconds is a real property of the sequencer, and from Kuala Lumpur the chain was four times faster than Base. MegaETH is still a new chain in its gated Frontier phase, and these look like the kind of infrastructure teething problems which should improve as the network matures. The question for us was whether it was ready for this application at that point in time, not whether the technology could improve.

The gap in this note is the distance between a chain property and an end-to-end path, and every stack has one.