Monad's MIP-8 Brings the EVM Closer to Real Hardware
Overview
May 7, 2026. Monad Foundation's May 6 post on MIP-8 is one of the clearest examples yet of Monad pushing performance work below the headline layer of throughput and into the part of the stack that actually determines how nodes touch state. The draft proposal does not ask developers to learn a new EVM. Instead, it changes the storage abstraction so that protocol pricing and storage commitments start to resemble what SSD-backed machines are already doing underneath.
The Mismatch: EVM Slots vs. SSD Pages
The EVM models storage as a long list of 32-byte slots. Hardware does not. Modern SSDs read in much larger chunks, typically 4 KB pages, and one such page can hold 128 EVM slots. In a physically local layout, reading one slot would often bring another 127 nearby slots into memory at the same time.
Context
The problem is that Ethereum-style commitment structure destroys that locality. The current Merkle Patricia Trie hashes storage keys before commitment, which keeps the trie balanced but scatters logically adjacent slots across unrelated disk pages. That means contract data that looks grouped at the Solidity level can still behave like random disk I/O for a node.
What MIP-8 Changes
MIP-8 introduces a page abstraction into the EVM state model. Instead of treating each slot as its own independent unit, the proposal groups 128 consecutive slots into a 4 KB page. In the draft notation, page_index(slot) = slot >> 7 and offset(slot) = slot & 0x7F, which cleanly partitions the slot space into fixed-size storage pages.
Operational Impact
The gas model then follows the page. The first read from a page in a transaction is cold and pays the heavier charge. Additional reads from the same page are warm and much cheaper. Writes follow the same high-level principle. The trie also commits to whole pages, so the gas savings reflect real locality in the storage layer instead of an accounting fiction.
Why This Matters for Developers
For Solidity developers, the good news is that MIP-8 rewards patterns Solidity already tends to generate well. Structs, arrays, and packed state variables naturally sit in contiguous storage, so several related fields can benefit from one cold page access followed by warm reads. Mappings remain the dividing line. A single mapping(address => uint256) mostly behaves like it does today because the key is hashed, but a mapping(address => UserData) becomes more attractive because once the mapping entry is resolved, related struct fields can live together inside the same page.
Operator Actions
That creates a healthy bias away from multiple parallel mappings such as separate balance, debt, and rewards maps for the same user. Grouping that state into one struct is not just tidier. Under MIP-8, it becomes more aligned with how the node actually reads storage.
Why Infra Teams Should Care
For validators, RPC operators, and indexers, this is more than a developer gas optimization. The draft explicitly says the proof structure and several RPC surfaces would need updates, including `eth_getProof`, `eth_createAccessList`, `eth_estimateGas`, `eth_call`, and `trace_call`. The MIP also introduces page-level commitment details around page hashes and induced proof structure, which means this proposal sits at the intersection of disk I/O, proof construction, and state access pricing.
Risk Watch
That is why MIP-8 matters. It shows Monad continuing to optimize the EVM where execution meets the machine. This is not cosmetic scaling. It is protocol engineering aimed directly at reducing structural waste in the state layer while keeping the development model familiar.
Backward Compatibility and Risk
The proposal is intentionally designed to preserve standard EVM execution semantics. Contracts with contiguous layouts benefit automatically, while dispersed layouts are not broken. The main class of contracts that needs extra scrutiny is anything that relies on hardcoded assumptions about opcode gas for storage access.
That is also why the forum discussion matters. Open questions remain around exact gas scheduling, proof sizes, worst-case read amplification, commitment details, and how far Solidity developers would reshape layout patterns if the proposal ships. Those are healthy draft-stage questions, and they are exactly the sort of details that should be argued out before the optimization becomes invisible infrastructure.
- MIP-8 groups 128 contiguous EVM storage slots into 4 KB pages so storage pricing better matches SSD-backed node behavior.
- The first page access remains cold, but later reads and writes within the same page become warm and cheaper.
- Structs, arrays, and mappings to structs benefit most, while legacy dispersed layouts remain functional but less locality-friendly.
- Proof handling and RPC methods like `eth_getProof` and `eth_estimateGas` would need updates, making this highly relevant for builders and infra teams.