BitCtrl Upgrades Monad Testnet Validator to v0.16.0 as Cohort 1 Ahead of MONAD_TEN

BitCtrl Upgrades Monad Testnet Validator to v0.16.0 as Cohort 1 Ahead of MONAD_TEN

Overview

August 5, 2026.

BitCtrl has upgraded its Monad testnet validator to `v0.16.0` as part of Validator Cohort 1. The validator is back online and advancing blocks ahead of the MONAD_TEN hard fork scheduled for August 12, 2026 at 14:30 UTC.

Context

This is the release that turns Monad's page-storage preparation into a network activation. v0.15.2 introduced dual-timeline support and allowed validators to build a page-encoded shadow database during MIP-8 Phase A. v0.16.0 sets the point where that page timeline becomes consensus-canonical on testnet.

For BitCtrl, the work was deliberately staged: complete Phase A first, verify both timelines, then install the hard-fork release when Cohort 1 was called.

MONAD_TEN Activates MIP-8 on August 12

Operational Impact

The v0.16.0 upgrade guide places the testnet hard fork at Unix timestamp 1786545000, which resolves to Wednesday, August 12 at 14:30 UTC. Mainnet activation is not yet set.

At that timestamp, MONAD_TEN activates MIP-8 page-encoded storage. The canonical execution state root changes from the legacy slot timeline to the page timeline network-wide in the same block.

Operator Actions

This is a protocol-level transition, which is why the version moves from v0.15.x to v0.16.0. Nodes must understand the new canonical storage commitment before they cross the activation boundary.

Phase A Is Now an Enforced Prerequisite

The most important operational change is enforced before the node even rejoins the network.

Risk Watch

v0.16.0 checks for an active page-encoded timeline on testnet. If a node has only an ethereum slot primary and has not completed Phase A, it aborts at startup. The supported pre-fork state is dual-database mode:

• primary timeline: ethereum, using slot encoding
• secondary timeline: monad, using page encoding

BitCtrl completed that migration during the earlier Cohort 1 Phase A window. The page secondary was populated from a finalized snapshot, both timelines were verified, and the validator returned to service with every committed block written to both databases.

That preparation made the v0.16.0 upgrade a controlled client rollout rather than an emergency database migration.

Before activation, slot and page timelines advance together with slot storage canonical. At the hard fork, page storage becomes canonical while the slot timeline temporarily remains as the shadow.

How BitCtrl Completed the Cohort 1 Upgrade

Before changing the package, BitCtrl verified that TrieDB still reported the required dual-timeline topology. That preflight matters because installing v0.16.0 on a slot-only node produces a startup failure by design.

The rollout then followed the published operating sequence:

• stop monad-bft, monad-execution, and monad-rpc
• reinstall the approved monad=0.16.0 package
• hold the package to prevent an unattended replacement
• restart all three services
• verify that each service is active and the validator is advancing
• confirm the running release with monad-rpc -V

The expected version output identifies the v0.16.0 tag and commit c616743d1358186605e1c1b74a3d6c4fdd9dd48c. The Category Labs release also identifies consensus commit c616743d1 and execution commit e81ffe31c.

BitCtrl completed those checks and returned the validator to normal participation. The node remains in dual mode until MONAD_TEN activates.

What Changes at the Fork

The hard fork changes which database timeline supplies the canonical state root; it does not require another operator command at the activation timestamp.

Before the fork:

• slot storage is canonical
• page storage is the shadow
• both timelines process every committed block

At and after the fork:

• page storage becomes canonical
• slot storage becomes the shadow
• the node remains in dual mode until Phase C

A later Phase C procedure will promote the page timeline to on-disk primary and decommission legacy slot storage. That cleanup is separate from the August 12 activation and should only be performed under the published post-fork instructions.

v0.16.0 Also Hardens the Client

MIP-8 activation is the headline, but the release includes several defensive changes around it.

The client now rejects storage keys longer than 32 bytes, bounds the MPT promotion target to a valid ring selector, strengthens the secondary Raptorcast client, and throws when maximum contract code size is exceeded. Snapshot handling also raises file-descriptor limits and reports open failures more directly.

The execution path receives a signextend code-generation improvement, while several storage-read and page-to-slot paths are simplified internally. These are not separate operator actions, but they reduce ambiguity and harden the code surrounding the storage transition.

Metrics Are Enabled by Default

The release enables the Prometheus metrics endpoint by default on 0.0.0.0:9143/TCP. Operators who previously treated metrics as opt-in should review firewall and network-policy rules.

A default listener is useful for observability, but it should not become an unintended public endpoint. BitCtrl is treating the port change as part of the release verification rather than assuming existing access controls cover it automatically.

Through the activation window, monitoring focuses on:

• validator participation and missed rounds
• service restarts and process health
• slot and page timeline advancement
• primary and secondary state-root logging
• disk utilization and dual-write behavior
• metrics exposure on port 9143

What Other Operators Need to Know

Full-node, RPC, and archive operators can upgrade before the hard-fork deadline, but must already have a page timeline available. Validator upgrades are coordinated in cohorts and should begin only after the operator receives its official instruction.

The practical preflight is simple: run monad-mpt --storage /dev/triedb and confirm both the ethereum primary and monad secondary are active. A slot-only result is a stop condition, not a reason to try the upgrade and troubleshoot afterward.

Operators should also verify the approved release, package hold, service health, block advancement, and metrics exposure after restart.

Bottom Line

v0.16.0 is the point where MIP-8 moves from preparation to activation on Monad testnet.

BitCtrl's Cohort 1 validator has completed the required client upgrade and is operating with both storage timelines ready. The remaining task is disciplined monitoring through the hard-fork boundary, when the page database that has been shadowing the chain becomes the source of canonical state.

The rollout shows why Monad separated database construction from protocol activation: validators were able to build and verify page storage in advance, then upgrade in cohorts without compressing every operational risk into the fork window.

BitCtrl is ready for MONAD_TEN.

Sources

• Monad testnet v0.16.0 upgrade instructions
• Category Labs monad-bft v0.16.0 release notes
• MIP-8 Phase A page activation