Monad Is Reworking EVM Storage Around How Modern Hardware Actually Works

Smart contracts address persistent state as individual 32-byte slots, while the storage stack beneath a node reads, writes, transfers and caches data in larger units. That mismatch becomes protocol-visible on Monad on September 2, 2026: instead of treating every slot as an independently located storage object, MIP-8 groups nearby EVM words into 4,096-byte pages and prices access around the locality those pages create.

Category Labs released monad v0.16.1 and monad-bft v0.16.1 on August 25. The releases schedule the MONAD_TEN activation for Unix timestamp 1788359400, or September 2, 2026 at 14:30 UTC. As of August 28, that activation remains scheduled rather than active.

The software release and the storage proposal handle different protocol layers. v0.16.1 encodes the mainnet activation time and refuses to start unless a page-encoded timeline is available as either the primary database or an active secondary; MIP-8 defines the page-encoded trie, page commitments and storage gas schedule that take effect at activation. MIP-8 is currently marked Final; the Monad Foundation explainer published May 6 called it a draft because that was the proposal’s status when the post was written.

The underlying problem begins with Ethereum-style Merkle Patricia Trie key hashing. Even if a contract stores fields in sequential slots, the trie hashes their keys before placing them, sending logically adjacent values down unrelated trie paths and, ultimately, toward unrelated database and disk regions. A contract may see slots 20, 21 and 22 as neighbors, but the node cannot rely on that adjacency when fetching or committing their values.

MIP-8 restores that relationship by dividing a contract’s storage keyspace into protocol-level pages. Each page contains 128 consecutive 32-byte EVM words, for a total of 4,096 bytes: the page index comes from the upper bits of the slot key, while the lower seven bits select a word inside the page. The trie then commits {page_index, page_commitment} pairs instead of independently locating every word as its own trie leaf, making the grouping part of consensus state rather than an optional database optimization.

That 4,096-byte unit should not be read as a promise about one particular storage device. A MIP-8 page is not necessarily identical to an SSD NAND page, filesystem block, database page, cache line or single physical I/O operation; real behavior still depends on alignment, caching, compaction and the node’s database implementation. The protocol-level claim is narrower and more useful: the commitment scheme keeps 128 consecutive words together, and the gas schedule recognizes repeated access within that logical unit.

For SLOAD, every storage access pays a BASE_COST of 100 gas. The first read from a page during a transaction additionally pays the 8,000 gas LOAD_COST, making that access 8,100 gas; subsequent reads from any other word in the same page avoid another load charge and pay the 100 gas base cost. This is not a blanket storage discount—it is an explicit price for page locality, paid once and then amortized when a transaction uses more of the data already grouped into that page.

SSTORE is accounted for separately because loading existing state, changing a page and growing persistent state are different operations. Every access pays the 100 gas base cost and may pay the 8,000 gas page load charge; the first state-changing write to that page may add a 2,800 gas WRITE_COST, while net increases in persistent nonzero state can add a 17,000 gas STATE_GROWTH_COST. Reusing a warm page can remove another load charge, but it does not make writes free or erase first-write and state-growth costs.

The useful case is clustered application state. Consider a lending or derivatives transaction that needs an account’s collateral balance, debt, margin configuration and position status before deciding whether to borrow, withdraw or liquidate. If those fields occupy nearby slots, the first field pays to warm their page and the transaction can read the remaining fields without treating each one as an unrelated cold lookup; if the structure crosses a 128-word boundary, however, the first field on the next page triggers another load charge.

Existing Solidity layout rules determine whether an application captures that locality. A mapping(address => Position) hashes the address and mapping base slot to locate one entry, but once that entry is resolved, consecutive fields in Position extend from that anchor at consecutive offsets. Four parallel mappings—one each for collateral, debt, margin settings and status—hash through four independent base slots and will usually place the same user’s fields on unrelated pages, forcing the transaction to warm each page separately.

Structs, statically sized arrays, packed variables and dynamic-array contents can therefore benefit without changing the Solidity programming model. Dynamic arrays begin at a hashed base, but their contents are laid out consecutively from that point, allowing nearby elements to share pages. The limits are just as important: isolated reads, random sparse state, different mapping entries, ordinary single-value mappings and accesses crossing page boundaries still encounter additional cold-page costs, and independently hashed mapping values almost never share a page merely by chance.

Compatibility is functional, not economic. Solidity source patterns, deployed bytecode, transaction formats and contract results remain compatible because MIP-8 does not replace the EVM or change Solidity’s storage layout; it changes the representation beneath execution and the gas charged for storage access. Contracts that explicitly depend on hardcoded SLOAD or SSTORE gas assumptions are the exception, while proof- and gas-sensitive infrastructure must follow the new model: eth_getProof returns the page-aware proof structure, and eth_createAccessList, eth_estimateGas, eth_call, trace_call and access-list accounting must recognize page-level warming.

As of August 28, mainnet is listed in Phase A of the live page-storage migration. Nodes that completed Phase A write committed blocks to both slot-encoded and page-encoded timelines; at MONAD_TEN, the page timeline becomes canonical regardless of whether database tooling labels it primary or secondary. Ordinary nodes may decommission the slot timeline after authorization, while State Archive nodes retain it to preserve historical state.

The broader engineering thesis is that blockchain performance is not an isolated execution-speed or TPS problem. Monad is coordinating execution, state commitments, database layout, caching behavior and protocol pricing so that the abstraction contracts pay for more closely matches the work nodes perform.