Page-ified Storage (MIP-8)

Monad's MIP-8 makes storage cheaper for contracts that keep hot data on the same memory page. Does Perpl need it? A slot-by-slot look — and why the answer is already handled.

What MIP-8 changes

The EVM treats every 32-byte storage slot as independent, but the hardware underneath reads and writes in 4 KB pages — so fetching one slot drags in a whole page, 128× more than asked for. MIP-8 (a Monad Improvement Proposal, currently Draft) reprices storage to match: it groups 128 contiguous slots into one page, and charges the cold surcharge once per page instead of once per slot.

Page size
128 slots
Cold page · 1st slot
8,100
Warm slot · the rest
100
Opcodes
SLOAD / SSTORE
unchanged

Only the commitment layer (a BLAKE3 tree over each page, ~257-byte inclusion proofs) and the gas accounting become page-aware; SLOAD/SSTORE keep working exactly as before, so existing Solidity is untouched. The reward goes to layouts that keep co-accessed data contiguous: the first slot in a page pays 8,100, and every other slot the same transaction touches on that page pays 100.

What benefits in Perpl

A struct stored in a Solidity mapping occupies contiguous slots from its hashed base, so a whole instance lands inside a single 128-slot page. Perpl's two largest hot structs fit with room to spare:

By contrast, Position, Order and OrderLock are each fully bit-packed into a single 32-byte slot, stored one-per-mapping-entry. Each hashes to its own scattered page: one cold page per entry, with or without MIP-8. Deep-book matching walks many of these, and that cost is the floor page-ification cannot lower.

Open the slot inspector →

What that means in gas

Cold-access surcharge only — the unchanged 20,000 / 5,000 SSTORE base is never touched by the page model. Slot counts are the fields a representative operation reads or writes on one struct.

Operation (one struct)SlotsToday · MonadNineMIP-8Saved
Read a Perpetual's hot fields864,8008,800−56,000
Touch a counterparty Account540,5008,500−32,000
Update one Position18,1008,1000
Cancel / replace one Order18,1008,1000
Match a taker vs 10 resting orders20 · 1/page162,000162,000≈0
Realistic order/match suite — measured16.82M16.11M−4.2%

The per-operation rows are structural estimates (cold surcharge = distinct slots × 8,100). The final row is the empirical anchor: the full gas suite run under the MonadNext (MIP-8) versus MonadNine (current mainnet) gas model.

Per-scenario gas reduction from the Perpl gas report — MIP-8 (MonadNext) vs current Monad mainnet (MonadNine), across the 25-scenario suite. Single-operation transactions gain most (a 1-1 match −17.7%); batches of ten amortize the cold surcharge across many orders already, so they gain little (~2%). The suite-weighted mean is −4.2%.

The core finding: bit-packing and page-ification are substitutes

Perpl already packed ~40 Perpetual header fields into 4 slots and the whole Account balance/flags block into 2 — that is the co-location page-ification rewards, but done at the slot level. So there are few warm-eligible neighbour slots left to discount. Page-ification pays off hugely for contracts that spread data across many slots (a naive ERC-1155 balance table: 20 tokens = 1 cold + 19 warm ≈ 10k gas vs 162k scattered — 16×). Perpl took the other, strictly-better road.

The verdict

MARGINAL · NOT SUBSTANTIAL The layout is already page-optimal, so little marginal gas is left to capture on the realistic order/match path. −4.2%

Page-ification is a modest win for Perpl as the contract is exercised today, not a structural upgrade. The one place a larger number could still hide — and the single-account suite does not exercise it — is batched, multi-perp / multi-account flow through the forwarder, where a single transaction mutates many structs and the per-page amortization compounds. That regime is the next thing worth measuring.