MegaETH onchain data: what one second of the chain contains

1. The clock is exactly one second wide

Start with the block headers, because they set the terms for everything else.

Five lines back, one per block:

One second per block. That holds for the whole window, and it holds more strictly than "about a second". Sweeping all 3,600 headers with includeAllBlocks and collecting the set of timestamp - number values returns a set with exactly one element:

So on MegaETH the block timestamp is the block number plus a constant. There is no jitter to observe, no slow blocks, no gaps. This is not an artifact of how SQD stores the data: the chain's own RPC at mainnet.megaeth.com/rpc returns 1786202259 for block 23,405,248 and 1786202260 for 23,405,249, the same constant, and reports chain ID 0x10e6 (4326).

It is also the documented design rather than a quirk. MegaETH runs two block types: mini-blocks every ~10ms with microsecond-resolution timestamps, and EVM blocks every ~1s with the standard one-second resolution, which is what indexers and wallets see.

Two consequences follow for anyone querying this chain. First, a time-bucketed query is a block-number query with extra steps, and you can convert either way in your head. Second, and this is the part that bites later, the block header cannot tell you anything about ordering or latency inside a second. If you want sub-second detail on an EVM block stream, it has to come from the event payloads.

One more header fact, since it frames the transaction section: the block gas limit is 10,000,000,000, on both Portal and the chain's own RPC. Mean gas used per block over the hour was 8,930,064 and the heaviest block used 29,633,254, so the average block used 0.0893% of the limit.

2. What 96,403 transactions actually are

A transactions request with no filter returns every transaction in the window, one NDJSON line per block:

Tallying what comes back: 96,403 transactions across the 3,600 blocks, 26.78 per block. 163 reverted, which is 0.17%. Grouping by sender and recipient shows the shape: the hour has 1,261 distinct senders but only 98 distinct recipient addresses.

Three flows dominate, and each runs at a rate that does not vary by a single transaction from block to block.

Those three account for 75,600 transactions, or 78.4% of the hour. The first is MegaETH's Oracle system contract at 0x6342…0001, a key-value store for offchain data, fed by a single sender at 10 transactions per block with selector 0x01caec13. It emits no logs at all, so it is invisible to anything that only watches events. The third is a type 0x7e deposit transaction, one per block, from the depositor account 0xdead…0001 to the L1 attributes predeploy at 0x4200…0015, the update that rollups post at the head of every block. The second is the subject of the next section.

The practical point: a transactions-per-second chart of MegaETH is mostly a chart of a constant. Strip the three fixed flows and the remaining traffic is 20,803 transactions from 1,254 senders in the hour, 5.78 per second. No sender appears in more than one group, so the rows reconcile with the totals: 1 + 5 + 1 + 1,254 senders is the 1,261, and 36,000 + 36,000 + 3,600 + 20,803 transactions is the 96,403. Both rates are true; they answer different questions, and a dashboard that does not separate them is not measuring usage.

Transaction types split 56,145 EIP-1559, 36,658 legacy, and 3,600 deposits. The legacy count is almost exactly the Oracle system-contract flow, which sends type 0.

3. A price feed emits 85% of all logs

129 contracts emitted a log during the hour, 463,893 logs between them. One address accounts for 395,984 of those, 85.4% of the total: 0x897a…6acd. It receives 10 transactions per block from five separate senders, two each, and emits 110 logs per block. Every one carries the same topic0 and no indexed parameters, so all the content is in the data field. Ask for one block and the response is a single NDJSON line: the block header plus a logs array holding all 110 matching logs.

That is the response with line breaks added, cut after the first log; the remaining 109 objects have the same shape and every value shown is untouched. Five 32-byte words in the data field. The contract is not verified on the explorer and no plausible event signature keccaks to that topic0, so the field names below are read off the payload rather than taken from an ABI:

The 1e8 scale is not an assumption. Decode every symbol in one block and the two dollar stablecoins land where they must, which is what fixes the divisor:

Over the full hour that is 395,984 logs: 11 symbols at 10 updates per block for 3,600 blocks, which would be 396,000. The 16 that are missing are section 5.

4. Measuring publish lag on a one-second clock

Words 2 and 3 are both microsecond timestamps, and they are not equal. Word 3 always sits on a clean 100ms grid (…523000000, …523100000, …523200000) while word 2 is tens of milliseconds later and irregular. Read as a publish time and an observation time, their difference is how stale a price is by the time it is on the chain.

Across all 395,984 logs in the hour:

A median of 24.5 milliseconds, with a tail to 127. The block header this data arrives in has one-second resolution and cannot express any of that. Ten distinct observations, each with its own sub-second timing, share a single block.timestamp. Anything that buckets this feed by block timestamp throws away the entire measurement and reports a flat 1-second cadence.

It also means the feed's real resolution is 100ms rather than the one second the block clock suggests. If you are pricing anything against it, that is the number that matters, and it is only in the payload.

5. The 1.7 seconds MEGA went missing

Ten of the eleven symbols publish exactly 36,000 times in the hour. MEGA publishes 35,984. Counting per symbol per block locates the shortfall in two adjacent blocks:

The MEGA observation grid stops after …523200000 and resumes at …524900000. That is a 1.7-second hole, which on a 100ms grid is 16 missed ticks, and 396,000 minus 16 is 395,984. The arithmetic closes exactly.

Every other symbol published normally through both blocks, so this is one publisher stalling on one symbol, not a chain-level event, and no block was slow: the header cadence is still one per second through the gap. The last quoted MEGA price before the stall and the first one after it are both 0.035484, so nothing moved while the feed was out.

The reason this is worth writing down is that it is invisible at every level of aggregation above the individual log. It does not show up in transaction counts, because all ten feed transactions landed in both blocks. It does not show up in the price series, because the price was unchanged. It shows up only if you count events per symbol per block across the whole window, which means reading all 395,984 of them.

6. Reproduce every number

This script runs the whole feed census: one stream over the pinned range, positional decode, per-symbol counts and the lag percentiles. It needs @subsquid/pipes and nothing else.

The script's own output, on @subsquid/pipes 1.0.0-beta.1. Pipes also writes progress lines to the log as it streams; those are left out here.

Same 395,984, same 110.00 per block, same percentiles, same per-symbol counts including the short MEGA row, all matching the raw curl path from the earlier sections. Two independent code paths over the same window agreeing to the log is the check that the decode is right.

7. Why this is awkward over RPC

Nothing above needs contract state, an archive node, or a paid debug endpoint. It needs one thing: every log and every transaction in a range, cheaply enough that scanning an hour is not a project. That is the part a JSON-RPC endpoint makes hard, and the block rate is why.

At one block per second, MegaETH produces 86,400 blocks a day and 31.5 million a year. The transaction census in section 2 needs full transaction bodies, which over RPC is eth_getBlockByNumber once per block: 3,600 round trips for the hour, 86,400 for a day. Against Portal you state a fromBlock and a toBlock and read NDJSON back. Both censuses here came back in one response each, though that is a property of this hour rather than a guarantee: a response covers as much of the range as fits, and past that you resume from the last block it returned. The loop is a few lines and it is driven by payload size, not by a provider's cap on how wide a window you are allowed to ask for.

The MEGA gap is the clearest illustration. Finding it required a per-symbol, per-block count over the full hour. If each attempt at that question costs thousands of requests, you do not ask it, and a 1.7-second outage in a price feed stays unnoticed. If it costs one request, you ask it while you are still exploring.

MegaETH is one of the networks Portal serves with the same request shape, so the queries here change by one word to run against another chain. The MegaETH chain page has the dataset details.