When Monad Foundation announced the MIP-8 migration, most validators focused on one thing: the upgrade steps.
Stop the services.
Upgrade to v0.15.2.
Activate the secondary timeline.
Dump a snapshot.
Load the snapshot.
Start the services again.
The entire process takes around 10 minutes.
The documentation explains how to perform the migration very well.
In this article, we'll take a closer look at the architectural ideas behind MIP-8 and what they mean for validators
Why is this migration necessary?
This article explains MIP-8 from a validator operator's perspective, without requiring a background in database engineering.
The old database
Before MIP-8, every Monad node stored its state using what Monad calls the ethereum state machine.
This does not mean Monad stored Ethereum blockchain data.
It simply refers to the original storage format inherited from the EVM model.
During the migration you may have seen something like this:
Primary:
State machine kind: ethereum
That is completely expected.
What is a storage slot?
Every smart contract stores its data in storage slots.
A storage slot is always 32 bytes.
For example, imagine a contract containing several variables:
balance
totalSupply
reward
lastClaim
Internally these are stored in storage slots.
Whenever a transaction executes, the EVM continuously reads and writes these storage slots.
Almost every storage modification follows this pattern:
Read storage
↓
Modify value
↓
Write storage
The problem with slot encoding
Before MIP-8, every storage slot was stored independently.
Think of it like a huge filing cabinet.
Instead of keeping related documents together, every document is placed into a random drawer.
For example:
Slot 0 → Drawer A
Slot 1 → Drawer X
Slot 2 → Drawer M
Slot 3 → Drawer Z
Now imagine a transaction needs Slots 0, 1 and 2.
The database has to jump between several completely different locations.
The SSD can certainly do this, but thousands of random reads and writes become expensive.
SSDs don't like tiny random operations
A storage slot is only 32 bytes.
Modern NVMe SSDs, however, naturally work with much larger blocks.
Typically around 4 KB.
That means changing just one 32-byte storage slot often requires the SSD to internally process an entire 4 KB block.
Multiply this by thousands of random storage updates every second and storage quickly becomes one of the limiting factors.
The MIP-8 solution: Pages
Instead of treating every storage slot independently, MIP-8 groups storage into pages.
A page is 4 KB.
Since every storage slot is 32 bytes, one page can contain:
4096 bytes / 32 bytes = 128 storage slots
Instead of scattering related slots across the database, Monad now groups them together.
Conceptually:
Page (4 KB)
Slot 0
Slot 1
Slot 2
...
Slot 127
The page doesn't need to be completely full.
Maybe only Slots 0, 1 and 2 contain data today.
That's perfectly normal.
The important difference is that these related slots now live together.
Locality is the real improvement
One common misconception is that MIP-8 is about making every 4 KB page completely full.
It isn't.
The real improvement is locality.
Instead of asking the SSD to visit many different locations, related storage is grouped together.
That means:
- fewer random reads
- fewer random writes
- better cache efficiency
- storage that better matches how modern SSDs already operate
Why did validators need downtime?
During the migration, Monad did not replace the existing database.
Instead, it created a second one.
Before the migration:
Primary
└── ethereum (slot encoding)
After Phase A:
Primary
└── ethereum
Secondary
└── monad
The node was stopped for approximately 10 minutes so it could:
- Create the secondary database.
- Copy the existing state into it.
- Verify that both databases contained the same blockchain state.
Once the node restarted, every new block began writing to both databases.
This is called dual-write mode.
Why keep two databases?
Because changing the storage engine of an entire blockchain is risky.
Instead of switching everything overnight, Monad allows both storage formats to run simultaneously.
Every new block is written to:
- the original slot database
- the new page database
Only after every validator has completed this migration will Monad activate the network-wide hard fork.
At that point, the page database becomes the canonical database.
Later, the old slot database can be safely removed.
Will validators use less hardware?
Not immediately.
In fact, during the migration validators temporarily perform more work because every block is written twice.
The long-term benefits are different.
Rather than dramatically reducing CPU or RAM usage, MIP-8 makes storage significantly more efficient.
That gives Monad more room to scale transaction throughput without storage becoming the bottleneck.
Final thoughts
MIP-8 isn't simply another database migration.
It's a redesign of how Monad stores blockchain state.
Nothing changes for smart contract developers.
Nothing changes for users.
But underneath the hood, validators now have a storage engine that's much better aligned with how modern NVMe SSDs actually work.
Sometimes the biggest upgrades aren't the ones that add new features.
They're the ones that quietly remove tomorrow's bottlenecks before they become today's problems.