Monad Prepares MIP-8 Page Storage Migration: What Validators Need to Know

Monad Prepares MIP-8 Page Storage Migration: What Validators Need to Know

July 22, 2026.

Monad has published the operational framework for moving node databases from the current slot-encoded layout to the page-aware storage model introduced by MIP-8. For validators and full-node operators, this is one of the more consequential database changes in the network's current roadmap.

It is also important not to move early. The official Monad migration guide currently says do not run the procedure yet. Testnet and mainnet remain in the initial phase, releases and fork timestamps are still listed as TBD, and validators will migrate in coordinated cohorts after an official Foundation announcement.

The right action today is preparation: understand the state transition, reserve the operating window, confirm disk headroom, and build the verification and rollback checks before a cohort is called.

Why MIP-8 Requires a Database Migration

The EVM exposes contract storage as independent 32-byte slots. Physical storage hardware works in much larger units, typically 4 KB pages. Reading one slot from disk may therefore pull in a full page while most of that I/O goes unused. Hashing storage keys also destroys locality, scattering logically related values across the database.

MIP-8 changes that relationship. It groups 128 consecutive storage slots into one 4 KB page, making the storage commitment and gas model aware of the hardware-sized unit the node is actually reading. The Monad Research Forum discussion describes the first page access as expensive and subsequent accesses to slots in the already-loaded page as warm.

For developers, that rewards contiguous layouts such as structs and arrays. For node operators, the immediate concern is different: page-aware state uses a different on-disk trie encoding, so existing databases must be migrated before page storage becomes canonical.

The MIP Land explainer provides a useful visual model of this shift, showing how page-aligned access reduces random I/O and changes storage gas behavior.

The Migration Avoids a Genesis Resync

Monad is not proposing an in-place rewrite of the live database. Instead, the node runs two complete state timelines during a controlled transition window:

• the existing ethereum state-machine kind holds the legacy slot encoding
• a new monad state-machine kind holds the page encoding

The migration creates the page database as a secondary timeline, loads the existing logical state into it through a binary snapshot, and then dual-writes new committed blocks to both encodings. The slot timeline remains canonical before the fork while the page timeline shadows it.

This design allows the new encoding to be populated and verified while the chain continues using the old state root. It also avoids forcing every existing validator to resync from genesis.

The migration moves from one slot timeline to a dual-write window, crosses a chain-wide fork where page storage becomes canonical, and ends with a single page-encoded timeline.

Three Phases, Two Operator Windows

The published process has three phases. Phase A and Phase C require per-node operator work. Phase B is the network-wide hard fork.

Phase A: Activate and Populate Page Storage

Each node is stopped, the page secondary is activated, and a binary snapshot is dumped from the latest finalized version of the slot primary. That snapshot is then loaded into the secondary, which re-encodes the state into page form.

After restart, the node enters Dual mode and commits every new block to both timelines. In a validator cluster, this work is rolled one node at a time. Operators should wait for each node to rejoin and for the chain to continue advancing before moving to the next machine.

Every validator and full node must complete this phase before the fork-setting release ships.

Phase B: The Hard Fork Flips Canonical State

The fork timestamp will be encoded in a later network release. It is not selected by individual operators.

Before the fork, the slot timeline supplies the canonical state_root, while page storage shadows it. At and after the fork, page storage supplies the canonical root and the slot timeline becomes the shadow. The node remains in Dual mode through this handoff.

This distinction matters: on-disk primary and consensus-canonical are separate concepts. Operators do not need to promote every database at the same instant for the chain-wide state-root switch to occur.

Phase C: Promote Page Storage and Remove Slot Storage

After the fork, each node is stopped again. Operators promote the page secondary to on-disk primary, deactivate the now-stale slot timeline, and restart into a single page-encoded database.

This phase can be staggered across the fleet. It does not need to happen immediately after the fork, but operators should not leave nodes dual-writing indefinitely because the temporary mode consumes additional resources and has a bounded history window.

The Invariant Operators Cannot Violate

The engineering runbook states the central rule plainly: every node must activate and populate its page secondary before the chain crosses the fork.

A slot-only node cannot follow the page-canonical timeline after activation. It fail-stops cleanly without corrupting the database, but recovery is forward-only. The operator must populate page storage and rejoin through statesync, or hard-reset and rebuild the node directly as page-only.

The opposite mistake is also dangerous: operators must never promote the page secondary before the fork. The tooling allows the ring promotion, but pre-fork blocks are still committed under slot encoding. A premature promotion causes the node to fail-stop on its next commit.

Verification Is the Gate, Not a Final Check

The dual-write window exists to prove the new timeline before it becomes authoritative. During this period, every node logs both state roots for each block.

Operators must compare the page-secondary root for the same block across the full validator fleet. The slot and page roots differ because their encodings differ, but the page root must be identical on every node, and both timelines must advance block for block.

That fleet-wide agreement is the gate for the later fork-setting release. If page roots diverge before activation, the secondary can still be dropped, rebuilt, and verified again without touching the canonical slot timeline. If they diverge after the fork, the page root is already consensus-critical and the chain can halt.

Rollback Exists Only Before Activation

The migration tooling is designed with useful guardrails. Activate, promote, and deactivate operations are crash-safe and idempotent, so an interrupted offline command can be run again. Database tools also fail when the node is running because the storage pool is held exclusively.

Before the fork, an operator can abandon the migration by stopping the node and deactivating the page secondary. A bad secondary can likewise be removed and rebuilt while slot storage remains canonical.

After the fork, there is no rollback to slot storage. Page encoding is canonical, so all recovery paths move forward through page storage.

Production Costs to Plan Around

The engineering runbook highlights several costs that small test environments may hide:

• snapshot dump and load took roughly 8 minutes at the cited mainnet scale: about 5m 6s to dump and 3m 15s to load at block 78,929,901
• a node that falls far enough behind during that window may enter statesync after restart, extending downtime
• dual-writing can reduce throughput while both timelines are active
• a lagging secondary can pin historical data and increase disk pressure
• the page secondary retains bounded history, described as roughly three months at sub-second block times, so the migration window cannot remain open indefinitely

Operators should therefore treat Phase A as a real maintenance event, not a quick metadata toggle. Snapshot location, free capacity, expected catch-up time, alert suppression, quorum sequencing, and rollback ownership should all be decided before the cohort window opens.

What BitCtrl Is Preparing

BitCtrl is treating the MIP-8 migration as a staged database change with an explicit go/no-go gate. Preparation focuses on:

• confirming the approved page-store-capable client release before any command is run
• measuring snapshot dump and load time against the validator's actual database
• reserving disk headroom for the temporary second timeline
• rolling one node at a time and confirming healthy rejoin before proceeding
• collecting page-secondary roots at matched block heights across the cohort
• documenting the pre-fork abort path and the post-fork forward-recovery path separately

No migration action should begin until Monad Foundation publishes the official cohort instruction and supported release.

Bottom Line

MIP-8 is a protocol optimization with a very concrete operational consequence: the state database itself must change shape.

Monad's dual-timeline design gives operators a controlled path to make that change without replaying the chain from genesis. It preserves a pre-fork recovery window and creates time to verify the page encoding across the fleet before consensus depends on it.

That safety comes with discipline. Activate and populate before the fork. Verify roots before the fork-setting release. Never promote early. And once page storage becomes canonical, move forward rather than trying to return to the legacy timeline.

For now, the correct operator action is preparation and monitoring. The execution step begins only when the official cohort announcement arrives.

Sources

• Monad MIP-8 activation and page-storage migration guide
• Category Labs page-store migration engineering runbook
• Monad MIP-8 overview
• MIP-8 research forum discussion
• MIP Land interactive MIP-8 explainer