This MIP proposes an increase to the maximum active validator set from 200 to 300.
The current active validator set is capped at 200. Raising the cap expands participation without introducing abrupt load changes to the consensus layer (MonadBFT) or execution pipeline.
Specification
Parameters
Parameter
Current Value
Proposed Value
ACTIVE_VALSET_SIZE
200
300
ACTIVE_VALSET_SIZE SHOULD be increased from 200 to 300.
Consensus and Execution Layer Impact
This MIP affects the consensus layer (MonadBFT). The active validator set size directly governs the number of participants in each consensus round. The execution daemon is unaffected unless validator set membership is read by on-chain contracts, in which case any such contracts SHOULD be reviewed for compatibility.
The consensus daemon enforces ACTIVE_VALSET_SIZE as an upper bound on the number of validators eligible to participate in block proposal and voting at any given epoch. The selection mechanism for which validators fill the active set (e.g., by stake) is unchanged by this MIP.
Rationale
An increment of 100 represents a meaningful expansion (~50%) without dramatically altering the message complexity in MonadBFT’s voting rounds. Larger single-step increases carry higher risk of unforeseen performance degradation; smaller increments would add process overhead without proportionate benefit.
The increase allows for greater decentralization in the active set, enforcing stronger fault tolerance and economic security.
Backwards Compatibility
This MIP does not introduce backwards incompatibilities. The change is additive: existing validators in the active set are unaffected. The hard-coded ACTIVE_VALSET_SIZE = 200 MUST be updated to 300 to support the new parameter values prior to activation.
Security Considerations
Consensus scalability: Increasing the active validator set increases the number of messages exchanged per consensus round in MonadBFT.
Sybil risk: Expanding the set without changes to the stake-based selection mechanism does not meaningfully increase Sybil risk. No additional mitigations are required.
In support of MIP-9, with a suggestion to use testnet more aggressively
This MIP is well-scoped. The 50% increment is a reasonable step and the rationale is sound.
One observation worth noting: the primary cost of increasing ACTIVE_VALSET_SIZE in MonadBFT is not bandwidth — it is signature aggregation latency at the leader. MonadBFT operates on O(n) message complexity in the happy path; each validator sends a signed vote directly to the next leader, who must aggregate those into a QC before proceeding. At 300 validators and 400ms block times, this is unlikely to be the bottleneck under nominal load. Under sustained peak throughput, however, the relationship between n and round latency has not been empirically characterized at this scale on a live network.
A proposal for the testnet phase: rather than validating 300, CONSIDER targeting 500 as the testnet ceiling. Additionally, it would be informative to have a subset of willing operators run two consensus nodes under the same stake weight — this artificially increases the signature surface seen by the leader per round without requiring additional stake, and would surface degradation in QC collection time during view changes and reproposals.
For context: the HotStuff protocol family was originally specified with an explicit design target of 500–1,000 validators, and subsequent implementations have validated this range in production environments. MonadBFT’s improvements over baseline pipelined HotStuff — specifically its tail-forking resistance via mandatory reproposal and the NEC mechanism — do not introduce additional per-validator overhead in the happy path. There is therefore no architectural reason Monad cannot reach 1,000+ validators incrementally. The question is empirical, and the testnet is the right place to resolve it.
Suggested trajectory: ACTIVE_VALSET_SIZE = 300 for this MIP → testnet experiment at 500 with dual-node operators → data-informed follow-on MIP.
We agree with the updated proposal and are glad to see the active set increase to 300. We believe this is a positive step for the network, as it strengthens decentralization and broadens validator participation while still keeping the change measured and reasonable from a performance standpoint.
We’re happy to support this decision and believe it will benefit the long-term health of the network.
Greater participation = stronger fault tolerance, better economic security, and more room for high-quality operators like OnNode to contribute to the network’s long-term health.
This change opens the door for broader community participation while keeping performance rock-solid.
