storage pricing

Monad’s latest network upgrade restructures how contracts pay for data access, grouping storage into pages that dramatically reduce costs for sequential reads. This change reshapes gas economics for smart contract developers and could influence how applications organize their state storage going forward.

• MonadTen activated on mainnet September 2 at 14:30 UTC, replacing per-slot storage warming with 128-slot pages costing 8,100 gas on first access.
• Reading a second storage slot within the same page costs 100 gas instead of 8,100 gas, a 98 percent reduction versus the prior model.
• Sequential state variables and struct fields now share page-level discounts automatically, incentivizing developers to store related data adjacently.

• 8,100 gas Cost to warm a new 4,096-byte storage page on first SLOAD
• 100 gas Cost to read subsequent slots within an already-warmed page
• 128 Number of consecutive 32-byte storage slots grouped into each page
• Sept 2 Date MonadTen upgrade activated on mainnet at Unix timestamp 1788359400

Monad, an EVM-compatible blockchain designed for high throughput and low latency, deployed the MonadTen upgrade on mainnet on September 2, introducing a structural change to how the network charges for storage access. The MIP-8 proposal replaces the previous slot-by-slot warming model with a page-based system that groups 128 consecutive 32-byte storage slots, totaling 4,096 bytes, into a single unit for pricing purposes.

Under the new rules, the first read from any page costs 8,100 gas, while every subsequent read within that same page costs only 100 gas for the remainder of the transaction. This represents a fundamental shift in how smart contract developers should think about storage layout and access patterns when building applications on Monad.

Page-Based Pricing Cuts Storage Costs By 98 Percent For Sequential Reads

The operational difference is significant for contract execution. On Monad mainnet block 101672712, reading slot 0 cost 8,100 gas, reading slot 1 on the same page cost 100 gas, and reading slot 128, the first slot of the next page, cost 8,100 gas again. Under the prior MonadNine rules, both slot 0 and slot 1 would have each cost 8,100 gas independently, even when stored next to each other.

The same pair now costs 8,100 gas for the first read and 100 gas for the second, representing a 98 percent reduction on the second access when both slots fall within one warmed page. For contracts that frequently access multiple related pieces of data, this creates substantial cost savings that compound across hundreds of transactions.

The 128-slot grouping was selected to balance practical memory management with meaningful cost reductions. At 32 bytes per slot, a page spans 4,096 bytes, which aligns with common page sizes in modern operating systems. This design choice allows Monad validators to efficiently manage which pages have been loaded into the execution context during block processing.

Common Solidity Patterns Automatically Benefit From Page Discounts

The incentive structure aligns with how most developers already write smart contracts. Sequential state variables, struct fields, and array elements occupy consecutive storage slots by default in Solidity, so repeated reads are more likely to fall within a single warmed page and qualify for the lower 100-gas rate.

A contract containing a struct with multiple fields, for example, naturally benefits from the page model without any code changes. When a function reads the struct’s price, balance, and owner fields sequentially, only the first field access pays 8,100 gas, while the others cost 100 gas each. This matches developer intuition about data locality and performance.

Mappings, by contrast, generally resolve to dispersed pages across the storage space, but struct fields nested within a mapping entry remain contiguous and can still share a page’s discount. Complex nested data structures therefore reward careful organization, as developers who group frequently-accessed fields together will see lower transaction costs.

Developer Tooling And Compatibility Require Adjustments To MIP-8 Model

MIP-8 preserves EVM execution semantics while fundamentally changing the assumptions used by access-list builders, storage-proof systems, and gas estimators. EIP-2930 entries, which warm storage slots for later use, now operate on a page level under the new model. Proof formats must be updated to represent the page structure rather than individual slots.

Contracts that hardcode storage-opcode gas costs into their logic represent the main compatibility risk class. For development teams building on Monad, the practical takeaway is that data read together is cheaper when stored close together, creating a direct incentive to organize related state variables sequentially within contract state.

Teams migrating existing contracts from Ethereum or other EVM chains should audit their storage layouts and consider reorganizing state variables to maximize page-level locality. This is particularly important for high-frequency read patterns in protocols like token contracts, lending platforms, and decentralized exchanges where storage access costs directly impact user transaction fees.

Developers working on Monad applications will need to update gas estimation tools and access-list construction logic to reflect the page-based pricing model, and teams relying on hardcoded gas values in existing contracts should audit whether those assumptions remain valid under MIP-8.