BitCtrl Upgrades Monad Mainnet to v0.16.1 as a Cohort 1 Validator

BitCtrl Upgrades Monad Mainnet to v0.16.1 as a Cohort 1 Validator

August 28, 2026.

BitCtrl has upgraded its Monad mainnet validator to v0.16.1 as part of Cohort 1. The update follows our completed MIP-8 Phase A migration and prepares the validator for the mainnet activation of MONAD_TEN.

The fork is scheduled for Wednesday, September 2, 2026, at 14:30 UTC, corresponding to Unix timestamp 1788359400. Both the execution client, monad, and the consensus client, monad-bft, are released as v0.16.1.

This is an important distinction for anyone following the rollout: BitCtrl's software upgrade is complete, but the network-wide storage switch is still ahead. Installing the release does not activate MONAD_TEN before its scheduled timestamp.

The Mainnet Deadline Is Now Fixed

The execution release notes make this a required upgrade for mainnet nodes. Clients remaining on v0.16.0 or earlier after the activation boundary will continue using MONAD_NINE rules and diverge from the network.

| Release detail | Mainnet requirement | | --- | --- | | Execution client | monad v0.16.1 | | Consensus client | monad-bft v0.16.1 | | Hard fork | MONAD_TEN / MIP-8 | | Activation | September 2, 2026, 14:30 UTC | | Unix timestamp | 1788359400 | | Storage prerequisite | Completed Phase A with an active page-encoded timeline |

| Metrics exposure | Restrict 9143/TCP to trusted monitoring access |

Full-node, RPC, and archive operators need to prepare alongside validators. Validator operators should still follow Monad Foundation's cohort announcements rather than treating the existence of a release tag as permission to restart. BitCtrl completed this update in Cohort 1; this article is not a call for other cohorts to move ahead of their instructions.

Phase A Was the Preparation; This Release Sets the Switch

BitCtrl previously completed mainnet MIP-8 Phase A. That created a page-encoded timeline beside the existing slot-encoded database. Both representations then received committed blocks while slot storage remained canonical.

MIP-8 reorganizes storage into pages containing 128 consecutive slots, rather than treating each slot independently in the trie. For operators, this means maintaining a different state representation, not simply changing a configuration label.

The migration guide separates the rollout into three stages:

• Phase A: prepare the page timeline and maintain both encodings.
• Phase B: at the hard fork, page storage becomes canonical and slot storage becomes the shadow.
• Phase C: follow the post-fork instructions for promotion and legacy-storage handling.

The fork changes which state root the network uses. It does not automatically remove the other on-disk timeline. Operators should not treat the activation timestamp as permission to delete legacy data, particularly where archive or historical requirements apply.

The Prerequisite Is Enforced at Startup

One detail deserves particular attention: a missing page timeline breaks startup when the upgrade is installed, not only when the fork arrives.

The v0.16.1 release extends the page-timeline check to mainnet. The client requires a page-encoded primary or an active page secondary. For nodes still preparing for mainnet activation, the intended state is the completed Phase A arrangement: an ethereum slot primary and a monad page secondary.

The official pre-upgrade check is:

monad-mpt --storage /dev/triedb

Seeing only an ethereum primary means the prerequisite has not been met. Reinstalling the package does not substitute for completing the migration. The upgrade instructions also state that no breaking node.toml changes are required for this release.

Keep the Metrics Port Private

The other operational change is easy to overlook during a version upgrade. The metrics endpoint has been enabled by default since v0.16.0, listens on 0.0.0.0, and uses port `9143/TCP`. Operators moving to this mainnet release must account for that listener.

Monad Foundation's announcement recommends blocking the port from the public Internet. Listening on all interfaces does not prove a service is publicly reachable, but it makes firewall policy decisive.

The practical requirement is to deny unsolicited public access while allowing only the monitoring systems that actually need the endpoint. Review both host and provider-side rules, and verify the result from outside the server as well as from the trusted monitoring network. Do not open the port globally just to make a scrape succeed.

A Relevant Fix for Buffer-Ring Startup Failures

The consensus release notes include an improvement with particular relevance to BitCtrl's recent operations: the dataplane can now fall back gracefully when initial io_uring buffer-ring setup fails.

In our August 25 incident report, a reboot activated an incompatible kernel, and monad-bft failed with failed to create buffer ring. Recovery required returning to the documented known-good kernel.

PR #3201 addresses initial registration failure by logging the error and using the existing recv_from UDP reader. When registration succeeds, the multishot path remains in use. The change is deliberately limited: later buffer-ring recreation failures remain fatal.

This is a useful additional safeguard, not a blanket guarantee against kernel problems. It does not justify removing kernel controls or assuming that every fallback path has identical performance. Supported-kernel selection, logs, and post-restart observation remain part of responsible operation.

Upgrade Verification Still Matters

BitCtrl's completed Cohort 1 upgrade is the milestone reported here. For other operators, the official process pairs installation with verification: confirm storage readiness, stop the service stack, install the specified package, hold it against unattended version changes, then restart and confirm block progression.

A version check is part of that process:

monad-rpc -V

The reported tag should be v0.16.1. That does not, by itself, prove healthy participation. Service state, peer connectivity, and advancing blocks still need separate checks.

AI-generated editorial illustration. The terminal uses simplified release labels; it is not a capture of BitCtrl's production host or verification output. The banner is also illustrative.

A concise handover checklist for this release is:

• confirm the approved network and cohort before starting maintenance
• verify the active page timeline before installing the package
• verify the installed version and hold the Monad package against unintended upgrades
• confirm all required services return and the node advances blocks
• check that the public Internet cannot access 9143/TCP
• monitor the node through the fork rather than considering installation the final step

What Comes Next

Between now and September 2, the operational priority is keeping the prepared validator healthy while the wider fleet completes its rollout. At activation, the important checks become continued block progression, agreement with the network, and healthy page-state processing.

For delegators, this announcement concerns the software behind BitCtrl's existing validator. It is not a request to move assets, disclose keys, or change a delegation address.

BitCtrl has completed the Cohort 1 release update. The next milestone is the coordinated hard fork, followed by the remaining migration actions under the official mainnet instructions.

Sources

• Monad v0.16.1 upgrade instructions
• Monad execution v0.16.1 release notes
• Monad BFT v0.16.1 release notes
• MIP-8 activation and page-storage migration
• PR #3201: buffer-ring setup fallback

BitCtrl's completed Cohort 1 upgrade is operator-confirmed. Protocol requirements and release behavior are sourced from the official materials above; no private host telemetry is reproduced.