Methodology

For every contract creation since MONAD_NINE activation (block 62,466,234), the scanner records the deployed bytecode length. Creations are discovered via an Envio HyperSync transactions query over each block range, collecting every transaction whose receipt carries a `contract_address` (top-level CREATE; factory/internal CREATE2 spawns are not exposed as receipt creations on Monad). The bytecode itself is fetched via `eth_getCode`. Contracts whose deployed bytecode exceeds 24,576 bytes (EIP-170, the pre-MIP-2 ceiling) use MIP-2's `MAX_CODE_SIZE` raise.

source · Envio HyperSync (contract-creation discovery) + eth_getCode on the Monad RPC pool

For each successful deployment, the deployment transaction's `input` field equals the initcode length when the transaction is a top-level CREATE (`to == null`). Contracts whose initcode exceeded 49,152 bytes (EIP-3860, the pre-MIP-2 initcode ceiling) use MIP-2's `MAX_INITCODE_SIZE` raise.

Limitations. Contracts deployed by factories (`CREATE`/`CREATE2` inside another transaction) have their deployed bytecode captured but not their initcode - `tx.input` is the factory's calldata, not the spawned contract's initcode. Recovering the latter requires call traces, which are not currently indexed at scale for Monad. In practice all 200 sampled jumbo (>24KB) contracts were direct-CREATE, so jumbo-initcode coverage is effectively complete; the small-contract initcode dimension is partial.

source · eth_getTransactionByHash on the deployment tx; `input.length` measured client-side

MIP-3 changes the gas-cost formula for memory expansion from quadratic (`words² / 512 + 3·words`) to linear (`words / 2`), with an 8 MB hard cap per transaction. The change is a server-side pricing recompute - transaction receipts show only the final `gasUsed`, with no indication of which regime applied or how much memory was expanded. Detecting MIP-3 usage directly would require step-level execution traces (e.g. `debug_traceTransaction` with the `structLogger`) to recover peak memory per transaction and recompute the Ethereum-equivalent cost.

Limitations. Step-level tracing across every Monad transaction is currently infeasible (no trace-indexed source for Monad on Envio HyperSync; rpc.monad.xyz's `debug_traceBlockByNumber` is rate-limited below the chain's own block-production rate). Instead the page exposes a calculator so developers can compute the savings for their own use cases.

source · interactive calculator - no on-chain measurement

For every contract deployed since MONAD_NINE, the scanner walks the deployed bytecode as opcodes (skipping `PUSH1..PUSH32` immediate data) and looks for two patterns: the literal precompile address `0x…1001` (which Solidity emits for hardcoded `address(0x…1001)`), and the 4-byte function selector `0x3a61584e` (which catches contracts that load the address dynamically - from storage, calldata, or computation - but still invoke `dippedIntoReserve()`). Either signal counts a contract as statically MIP-4-aware.

Limitations. This counts contracts that *could* invoke the precompile, not the count of actual invocations. A contract with the bytes baked in might never take the MIP-4 branch in practice. For actual on-chain usage see the runtime sample below.

source · deployed bytecode of every scanned contract, opcode-aware walk

Once per day a sparse trace sample runs: 25 windows of 60 blocks each, evenly distributed across the post-MONAD_NINE range. Each block goes through `debug_traceBlockByNumber` (`callTracer`) on `rpc.monad.xyz` - the only Monad endpoint we have access to that exposes trace methods. The call tree of every transaction is walked, counting CALL frames where the destination is the MIP-4 precompile. (Per the MIP-4 spec, `dippedIntoReserve()` must be invoked via `CALL`; `STATICCALL`/`DELEGATECALL`/`CALLCODE` are forbidden and would revert. Non-CALL frames are reported separately as anomalies.) Each run covers ~1,500 blocks (~7 minutes of chain time) spread across 50+ days of history; the cumulative result is preserved.

Limitations. A true exhaustive runtime backfill is currently infeasible on the available infrastructure. `rpc.monad.xyz` sustains roughly 3 blocks/second of sequential tracing while the chain produces ~3.5 blocks/second, so brute-force scanning can't even keep pace, let alone backfill 14M+ blocks of history. The other Monad pool endpoints (`rpc1/2/3`) reject trace methods (403). Envio HyperSync does not currently index Monad trace data - confirmed empirically. Until either of those changes, runtime usage is reported as a sampled estimate, not a complete count.

source · debug_traceBlockByNumber + callTracer on rpc.monad.xyz

For every contract deployed since MONAD_NINE the scanner walks the deployed bytecode as opcodes (skipping `PUSH1..PUSH32` immediate data) and counts contracts that contain the new CLZ opcode (byte 0x1e). A naive substring check would false-positive on `0x1e` bytes appearing inside `PUSH32` payloads; the disassembly walk avoids that.

source · deployed bytecode of every scanned contract, opcode-aware walk

EIP-7823 caps each MODEXP (`0x…0005`) input-length parameter at 1024 bytes; calls exceeding it now revert. Measuring real exposure would mean counting MODEXP invocations and their input sizes — but MODEXP is a precompile invoked *internally* via CALL from other contracts, essentially never as a top-level transaction (an exhaustive HyperSync scan of the post-MONAD_NINE range found zero top-level calls to `0x…0005`). Internal precompile calls are only visible in execution traces, which Monad does not expose via HyperSync, and `debug_traceBlockByNumber` is rate-limited below the chain's block-production rate. So real usage is not measurable from available data. Context: the EIP author's historical-Ethereum analysis found the largest observed MODEXP input was 513 bytes — well under the 1024-byte cap — so real-world impact is expected to be nil.

source · not measurable — internal precompile calls require traces unavailable on Monad

EIP-7883 raises the gas cost for the MODEXP precompile (from `max(200, mc·ic/3)` to `max(500, mc·ic)`, with the multiplier for oversized exponents doubled). The change is a server-side pricing recompute: the same inputs and outputs occur, only the gas debit differs. Transaction receipts cannot distinguish the old regime from the new - they only show the final `gasUsed`. We document the change but do not publish a number.

source · documented only - no measurement