Monad onchain data: 94 million blocks, and every time the chain retuned itself

1. Starting at block 0, including the strange one

The dataset starts at block 0, so there is no gap between genesis and the head to work around. Ask for the first two blocks:

Block 0 carries timestamp 0 and gasLimit 0x1388, which is 5,000. Those are genesis placeholders, not measurements, and they are worth knowing about before you build anything on top: a block-time average that includes block 0 computes against the Unix epoch and returns a number 55 years wrong. Start at block 1.

Block 1 is timestamp 1747232689, which is 2025-05-14 14:24:49 UTC, and its gas limit is 0x8f0d180, 150,000,000. That is the real start of the chain and the baseline for everything below.

2. Three times the chain changed its own numbers

Sampling the header at 25 points across the 94 million blocks shows two fields that are not constant: gasLimit and, indirectly, the interval between timestamps. Bisecting on each gives this.

The gas-limit rows carry exact block numbers because gasLimit is a field, so a bisection lands on a single block. Block 33,442,486 reads 150,000,000 and block 33,442,487 reads 200,000,000, both stamped 2025-11-04 14:09:28 UTC.

The 2025-08-13 row does not, and the reason is worth stating rather than hiding behind a tilde. Block time is not a field, it is a rate between timestamps, and Monad's timestamps have one-second resolution while its blocks are twice a second or faster. Two adjacent blocks are either 0 or 1 second apart, which tells you nothing. You can only see the rate change across a window, and the best this method does is bracket it: the average is 0.5017 s/block up to block 15,596,138 and 0.4014 s/block from block 15,599,138, so the change is somewhere in the three thousand blocks between them, around 14:25 to 14:32 UTC. Anything more precise would be invented.

3. The block where two numbers moved at once

The most recent change is the interesting one, because both parameters moved together and the exact block is recoverable.

At block 89,656,735 the gas limit drops by a quarter and the block rate rises by about a third, in the same block. Multiply them out:

Capacity per second is the same on both sides, within measurement noise. The chain did not gain or lose throughput that day; it moved the same throughput into smaller, more frequent blocks, cutting the wait for inclusion by about a quarter while leaving the amount of work per second alone.

For anyone reading this chain, that combination matters more than either number on its own. A per-block gas budget that shrank by 25% means a transaction that used to fit may not, while a shorter block time means more blocks to scan for the same wall-clock window. Watching only gasLimit would have shown a capacity cut that did not happen.

4. What the capacity was for

Capacity changes are easier to read next to demand. Counting every transaction in a 10,000-block sample at intervals across the history:

The chain ran for about four months at effectively zero traffic, a few dozen transactions per ten thousand blocks, then activity began around block 25,000,000 in late September 2025 and has climbed since. The first capacity increase, the block-time cut in August 2025, landed before any of it. The second, the gas-limit raise on 2025-11-04, landed while per-block traffic was going through 1.34 and about to reach 8.

Two 20,000-block sweeps give the fuller picture at either end of 2026. At block 60,000,000 in March: 134,962 transactions, 6.75 per block, 16.9 per second, using 1.42% of the block gas limit. At block 94,000,000 in August: 266,722 transactions, 13.34 per block, 44.2 per second, 7.00% of the limit. Throughput roughly doubled in five months, and the chain still uses a single-digit share of the capacity its headers advertise.

5. Reproduce it

This reads the 6,001 blocks around the upgrade, groups them by the gas limit in their header, and prints the block time and the resulting capacity for each group. It is the whole of section 3 in one file.

Output, on @subsquid/pipes 1.0.0-beta.1:

Two groups, one boundary, and the capacity figures land four million gas per second apart on either side of a change that moved both inputs. Nothing in the script knows the upgrade happened; it falls out of grouping the headers.

The coverage line is not decoration. By default Portal returns only blocks with matching data, and an empty logs filter matches every log, not every block. In this window every block carries at least one log, which the script proves by counting what it received against the full range; a header-only block would have made that line read short instead of silently shrinking an era.

6. Why this needs the whole history

Every finding on this page is a header field, which is the cheapest data a chain has. The difficulty is not the fields, it is needing all 94 million of them.

Bisecting for each gas-limit change took about two dozen single-block reads, which any endpoint can serve. Establishing that there were exactly two such changes did not: that came from sampling the full range first, and a sample that misses a window misses a change entirely. The 2025-08-13 block-time cut is invisible in any single block and only appears when you can average across arbitrary windows on demand, cheaply enough to do it repeatedly while narrowing down.

That is the shape of the problem: not one expensive query, but hundreds of cheap ones spread across fifteen months of history, where each answer decides the next question. Over an archive node this is a project. Against a dataset that starts at block 0 it is an afternoon.

The same request shape runs against every network Portal serves, so the sampling above is one word away from any other chain. The blockchain data API guide covers the request format itself, including the continuation behaviour the sampling here relies on.