BitCtrl Completes Monad Testnet v0.15.2 Upgrade and MIP-8 Phase A as a Cohort 1 Validator

BitCtrl Completes Monad Testnet v0.15.2 Upgrade and MIP-8 Phase A as a Cohort 1 Validator

Overview

July 29, 2026.

BitCtrl has upgraded its Monad testnet validator to `v0.15.2` and completed MIP-8 Phase A page activation as part of Validator Cohort 1.

Context

This rollout is more than a routine package update. v0.15.2 introduces the dual-timeline storage capability needed for Monad's transition from the current slot-encoded state database to MIP-8 page-aware storage. Phase A then uses that capability to build a page-encoded copy of the validator's state and keep it synchronized before the network depends on it.

BitCtrl's validator is back online in dual-write mode. The existing slot timeline remains canonical. A new page timeline runs beside it as a shadow, processing the same committed blocks and producing the state that will become canonical only after a later network-wide hard fork.

What v0.15.2 Changes

Operational Impact

The official v0.15.2 instructions describe no breaking node.toml changes, but the release introduces several operationally relevant updates.

Most importantly, it adds support for a secondary page-encoded TrieDB timeline and the monad-mpt and monad-cli operations used during Phase A. That support is the prerequisite for the one-time database migration.

Operator Actions

The release also changes the eth_call execution-revert error code from -32603 to 3. Integrations that match the old code should be updated. Operators using Prometheus CLI flags can move those settings into the [prometheus] section of node.toml, custom full_node_raptorcast.round_span values must be no greater than 960, and scripts using monad-sign-name-record must replace the old combined address flag with separate IP, TCP-port, and UDP-port arguments.

BitCtrl stopped the Monad services, installed and held the approved 0.15.2 package, restarted the stack, and verified the running version. The expected monad-rpc -V output carries the v0.15.2 tag and release commit 6373056bfa14318d2a6d7a371cc43c636bf0aab6.

Phase A Is a Separate Database Operation

Risk Watch

Installing v0.15.2 makes page activation possible; it does not populate the new timeline automatically. That work happens during MIP-8 Phase A, and validators must run it only when their assigned cohort is announced.

For BitCtrl, the Cohort 1 procedure followed the published sequence:

• stop monad-bft, monad-execution, and monad-rpc
• raise the open-file limit required by the multi-shard snapshot operation
• repair TrieDB and activate a monad page-encoded secondary
• dump the latest finalized state from the existing primary timeline
• load that snapshot into the page secondary, re-encoding the same logical state
• remove the temporary snapshot and verify both timelines
• restart all services and confirm the validator is advancing blocks

The documentation estimates about five minutes to dump the snapshot and three minutes to load it. That roughly eight-minute data operation sits inside the wider maintenance window, which also includes service shutdown, verification, restart, and any required catch-up.

Phase A snapshots the finalized slot state, re-encodes it into page storage, and returns the validator to service with both timelines advancing together.

What BitCtrl Verified Before Returning to Service

A successful command is not enough for this migration. The operational result must show the intended database topology.

BitCtrl verified that TrieDB reports:

• primary state-machine kind: ethereum, representing legacy slot encoding
• secondary state-machine kind: monad, representing page encoding
• latest versions on both timelines aligned, with only the small block difference permitted during the procedure
• all three Monad services active and the validator advancing after restart

The validator's execution logs now emit both roots for committed blocks: a primary slot root and a secondary page root. Those roots are not expected to be identical because the state commitments use different encodings. What matters is that both timelines process the same chain continuously and that page roots agree across the validator fleet at matched block heights.

BitCtrl is also monitoring monad_triedb_migration_phase. A value of 1 confirms dual mode during Phase A and the later pre-decommission window.

MIP-8 Is Not Active Yet

Completing Phase A does not make page storage canonical and does not activate MIP-8 execution behavior.

Before the hard fork:

• slot encoding remains canonical
• page encoding remains the shadow
• every committed block is written to both timelines

Phase B will be a network-wide scheduled hard fork. Its timestamp will ship in a later chain release only after the validator set has completed Phase A. At that boundary, the canonical state root flips from the slot timeline to the page timeline in the same block. There is no per-validator action at the fork itself.

After activation, Phase C lets operators promote the page timeline to on-disk primary and remove the legacy slot timeline. Historical or state-archive nodes are an exception and retain slot storage under the current plan.

This separation is the core safety property of the rollout: build first, synchronize continuously, verify across the fleet, and only then make page storage consensus-critical.

Why Cohort 1 Matters

Rolling validators in cohorts limits operational risk and preserves network participation while each node takes its offline migration window. Cohort 1 is the first production test of that operator sequence across the assigned validator group.

For BitCtrl, completing the cohort means the validator is not merely running the page-capable binary. It has a populated page timeline, has rejoined consensus, and is producing the observability signals needed to assess the migration before later cohorts proceed.

That makes the current period a verification phase. Disk consumption, dual-write performance, service stability, state-root progression, and validator participation all matter while the page database remains a shadow.

What Other Operators Should Do

The instruction remains strict: do not run Phase A until Monad Foundation announces your cohort.

Before that window, operators should review the v0.15.2 integration changes, confirm sufficient TrieDB capacity, prepare the snapshot directory, ensure the open-file limit can be raised to 65536, and decide how they will verify both timeline heights and service recovery.

Once assigned, operators should follow the published commands exactly and avoid promoting the page timeline early. Before the fork, the slot timeline must remain primary and canonical.

Bottom Line

BitCtrl's Cohort 1 upgrade establishes the state Monad needs before MIP-8 can safely activate: one proven chain represented in two different database encodings.

The slot timeline still secures the canonical chain today. The page timeline is now built, synchronized, and observable beside it. That gives Monad time to validate page storage across the validator fleet before the fork makes it authoritative.

For BitCtrl, the upgrade is complete, the validator is back in service, and the work moves from migration to monitoring. The next milestone is not another local database command. It is coordinated completion across the remaining cohorts, followed by the network-wide MIP-8 activation.

Sources

• Monad v0.15.2 upgrade instructions
• MIP-8 Phase A page activation
• MIP-8 activation and page-storage migration overview