BitCtrl Upgrades Monad Mainnet Validator to v0.15.1 as a Cohort 1 Validator
Overview
July 16, 2026.
BitCtrl has upgraded its Monad mainnet validator to `v0.15.1` as a Cohort 1 validator. The upgrade is complete ahead of the protocol activation scheduled for Round 89,758,000, currently estimated for July 23, 2026 at approximately 14:30 UTC.
Context
This is a focused release, but it carries a hard operational deadline. v0.15.1 places the mainnet activation point for MIP-12 into the consensus client. Any mainnet node that reaches the activation round without the new version will not recognize the updated block reward and will fall out of consensus.
For operators, this is not a routine patch to leave until the last minute. It is a coordinated consensus upgrade.
What v0.15.1 Actually Changes
Operational Impact
The official release describes v0.15.1 as a consensus-only patch on top of v0.15.0.
The execution client is unchanged. The release keeps the same execution tag and commit used by v0.15.0, while the Monad BFT client moves to commit fb3328c2e and adds the mainnet activation values for the next consensus revision.
Operator Actions
The patch sets two changes to activate together at Round 89,758,000:
- the
MIP-12vote-pacing and block-parameter update - the block reward change from 25 MON to 18 MON
The implementation was merged through monad-bft PR #3168, which updates the mainnet chain configuration and reward activation round.
MIP-12 Moves the Vote Pace From 400ms to 300ms
Risk Watch
The most visible change is a reduction in consensus vote pacing:
- current vote pace: 400ms
- new vote pace: 300ms
Vote pacing sets the minimum timing floor for consensus progress. Reducing it allows the network to advance sooner when quorum has already been achieved, tightening the path toward faster block production without changing the execution client.
That does not mean Monad is simply packing the same block size into a shorter interval. MIP-12 proportionally adjusts the per-block limits:
- transaction limit: 5,000 to 3,750
- proposal gas limit: 200 million to 150 million
- proposal byte limit: 2 million to 1.5 million
Those reductions are proportional to the move from 400ms to 300ms. The design preserves the same broad throughput envelope per second while dividing work into smaller, more frequent blocks.
The activation tightens consensus cadence while proportionally reducing work per block, allowing more frequent blocks without mechanically expanding the network's per-second limits.
Why the Reward Changes at the Same Time
More frequent blocks would increase reward issuance if the per-block reward remained unchanged. MIP-12 therefore changes the block reward from 25 MON to 18 MON at the same activation round.
The MIP describes this as a proportional adjustment to account for the faster block cadence. It keeps the economics closer to the existing issuance profile instead of letting a timing improvement create an unintended reward increase.
For validators and delegators, the important point is that reward accounting changes with the consensus parameters. That is why old clients cannot safely remain connected after the activation boundary.
BitCtrl Completed the Cohort 1 Upgrade
BitCtrl completed the v0.15.1 rollout as part of Cohort 1, placing the validator on the required consensus version ahead of activation.
The operational sequence includes stopping the Monad services, installing and holding the approved package version, restarting the stack, and verifying the active binary version. Nodes upgrading directly from v0.14.5 or earlier also require a one-time database metadata migration; nodes already on v0.15.0 can skip that migration step.
Completing the package upgrade is only the first checkpoint. BitCtrl will continue monitoring:
- validator participation and missed rounds
- peer connectivity and consensus message flow
- proposal and finalization timing
- service health across BFT, execution, and RPC
- reward behavior after the activation round
The goal is not simply to report that the package was installed. It is to remain stable through the point where the new parameters become live network behavior.
What Other Operators Need to Know
The official instruction is unambiguous: all Monad mainnet nodes must upgrade to v0.15.1 before Round 89,758,000.
Testnet operators should remain on v0.15.0 until further notice. The v0.15.1 instructions currently apply to mainnet only.
Mainnet operators should verify the running version with monad-rpc -V and confirm the v0.15.1 tag and consensus commit. They should also keep the Monad package on hold so an unattended system upgrade cannot replace the approved network version.
Bottom Line
v0.15.1 is small in code scope and large in coordination impact.
It does not replace Monad's execution engine or introduce a new transaction model. It prepares the consensus layer for a tighter operating cadence, with faster vote pacing and proportionally adjusted block parameters.
BitCtrl has completed that preparation in Cohort 1. The next checkpoint is Round 89,758,000, when the upgrade stops being installed software and becomes the live behavior of Monad mainnet.
Sources
- Monad v0.15.1 upgrade instructions
- Monad BFT v0.15.1 release
- Monad BFT PR #3168
- MIP-12: Decrease Block Time
- BitCtrl has upgraded its Monad mainnet validator to v0.15.1 as a Cohort 1 validator.
- All mainnet nodes must run v0.15.1 before Round 89,758,000, expected around July 23, 2026 at 14:30 UTC.
- MIP-12 reduces vote pacing from 400ms to 300ms and proportionally lowers per-block transaction, gas, and byte limits.
- The block reward changes from 25 MON to 18 MON, while the execution layer remains unchanged.