BitCtrl Completes Monad Mainnet MIP-8 Phase A as a Cohort 1 Validator

BitCtrl Completes Monad Mainnet MIP-8 Phase A as a Cohort 1 Validator

Overview

August 18, 2026.

BitCtrl has completed MIP-8 Phase A on its Monad mainnet validator as part of Validator Cohort 1. The validator is back online, advancing blocks, and operating with both the existing slot-encoded database and a newly populated page-encoded timeline.

Context

This is the first operational stage of Monad's mainnet transition to page-aware storage. It prepares the database that will eventually become canonical, but it does not activate MIP-8 at the protocol level. Slot storage still supplies mainnet's canonical state root today.

The distinction matters: BitCtrl has completed the database preparation safely and on schedule, while the network-wide hard-fork decision remains ahead.

Mainnet Has Entered Phase A

Operational Impact

Monad's public MIP-8 migration guide now lists mainnet in Phase A on release v0.15.2. The hard-fork timestamp remains TBD, and MIP-8 is not active on mainnet.

Phase A moves a node from one storage timeline to two:

• ethereum primary: the existing slot-encoded TrieDB
• monad secondary: the new page-encoded TrieDB

Operator Actions

The labels primary and secondary describe the on-disk arrangement. Before activation, the slot timeline is also consensus-canonical, while the page timeline shadows the same blocks and computes its own page-encoded state root.

This dual mode gives Monad a verification window. Validators can build, run, and compare page storage across the fleet before consensus depends on it.

What BitCtrl Completed in Cohort 1

Risk Watch

BitCtrl ran Phase A page activation only after Cohort 1 was called. The procedure required a controlled validator maintenance window rather than an in-place live conversion.

The operating sequence was:

• stop monad-bft, monad-execution, and monad-rpc
• raise the open-file limit to support the multi-shard snapshot
• prepare a clean migration snapshot directory
• repair TrieDB and activate a monad page-encoded secondary
• dump the latest finalized state from the slot primary
• load that snapshot into the page secondary
• verify both timeline heights and storage kinds
• restart all services and confirm the validator rejoined mainnet

The official estimate is approximately five minutes for the snapshot dump and three minutes for the load. The full maintenance window also includes shutdown, checks, restart, and any block catch-up required after rejoining.

Phase A stops the node, snapshots finalized slot state, re-encodes it into page storage, and restarts the validator with both timelines advancing together.

Why the Migration Does Not Require a Genesis Resync

MIP-8 changes the shape of the state database. Instead of committing every 32-byte storage slot independently, page encoding groups 128 consecutive slots into 4 KB pages. That changes the trie commitment and on-disk layout even though the logical contract state remains the same.

Replaying mainnet from genesis into a new encoding would be operationally expensive. Phase A avoids that by exporting the latest finalized logical state from the working slot database and loading it into the page secondary.

After the load, both timelines process each new committed block. The validator therefore carries two complete state representations forward from the same finalized point without interrupting the canonical chain or rebuilding its full history.

What BitCtrl Verified Before Restart

The critical output is not simply a successful snapshot command. TrieDB must report the intended dual-timeline topology:

• primary state-machine kind: ethereum
• secondary state-machine kind: monad
• primary and secondary latest versions aligned

A difference of a few blocks during the procedure is expected, with the documentation allowing up to roughly 10. After restart, the execution logs should emit both roots for each committed block:

• state_root primary=<slot root>
• secondary=<page root>

The two roots are not equal because they commit state using different encodings. The useful check is that both timelines advance continuously and that page roots agree between nodes at matched block heights.

BitCtrl confirmed the dual state, restarted the full Monad service stack, and verified that the validator returned to active block progression.

What Changes Operationally Now

The validator is now in dual-write mode. Every committed block updates both databases, which introduces temporary storage and write overhead until the migration completes.

BitCtrl is monitoring:

• validator participation and missed rounds
• service and process health
• primary and secondary timeline heights
• slot and page state-root progression
• TrieDB disk consumption
• snapshot cleanup and available capacity
• monad_triedb_migration_phase, which should report 1 in dual mode

The page secondary is not passive backup data. It is an actively maintained state timeline that must remain healthy because a later hard fork will make its root consensus-critical.

What Comes Next

Phase A is one part of a three-stage rollout.

Phase B will be a scheduled mainnet hard fork. The timestamp will be encoded in a later network release after the required nodes have completed Phase A. At that boundary, the page timeline becomes canonical and the slot timeline becomes the shadow in the same block. There is no individual operator command at the activation timestamp.

Phase C happens after activation. Operators will promote the page timeline to on-disk primary and decommission the legacy slot timeline to reclaim disk space. Historical and state-archive nodes are expected to retain slot storage under the current plan.

BitCtrl will not promote or remove either timeline before the official post-fork instruction.

Why the Cohort Model Matters

Phase A requires validator downtime, snapshot I/O, and a second database timeline. Running every validator through that process simultaneously would create unnecessary participation and recovery risk.

The cohort model spreads those maintenance windows across the validator set. It also lets Monad Foundation observe real migration duration, rejoin behavior, disk impact, and dual-write stability before progressing through the broader fleet.

As a Cohort 1 validator, BitCtrl's role is not only to complete the commands. It is to verify the operational path early, return to stable participation, and monitor the new timeline closely enough to surface problems before activation.

Bottom Line

BitCtrl's mainnet validator is ready for the next stage of MIP-8.

The page database has been created, populated, verified, and placed into continuous dual-write operation. The existing slot database remains canonical, so Phase A changes operational readiness without changing mainnet's protocol behavior today.

That staged approach is the point of the migration design: build the new state representation first, prove it across the validator fleet, and only then switch consensus to it at a coordinated hard fork.

For BitCtrl, Cohort 1 Phase A is complete. The validator is online, both timelines are advancing, and monitoring continues.

Sources

• Monad MIP-8 activation and page-storage migration guide
• Monad MIP-8 Phase A page activation
• Monad MIP-8 page-aware storage overview