Specification
## Abstract Decrease the block time by decreasing the consensus vote pace from 400ms to 300ms. Proportionally, decrease the following block parameters: transaction limit, proposal gas limit and proposal byte limit. Proportionally, also decrease the block reward. ## Specification We propose the following changes to the chain parameters on the consensus client: ### Chain Parameters | Chain Parameter | Current Value | Proposed Value | | --- | --- | --- | | vote_pace (ms) | 400 | 300 | | tx_limit | 5,000 | 3,750 | | proposal_gas_limit | 200,000,000 | 150,000,000 | | proposal_byte_limit | 2,000,000 | 1,500,000 | We also propose the following change to the staking parameters, to roughly account for the more frequent block times: ### Staking Parameters | Staking Parameter | Current Value | Proposed Value | | --- | --- | --- | | block_reward (MON)| 25 | 18 | ### Consensus and Execution Layer Impact This change should not affect the execution client in any way. The consensus client will vote on proposals 100 milliseconds faster than it does currently, leading to faster quorums and faster block times. ## Backwards Compatibility This change is backward compatible with the execution client. However, since the block parameters are used for consensus block validation, this change is not backward compatible with the consensus client and will require a hard fork on a round. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).
Forum discussion
-
mip 12 title Decrease Vote Pace description Decrease consensus vote pace from 400ms to 300ms author Category Labs status Draft type Standards Track category Core created 2026-06-01 Abstract Decrease the consensus vote pace from 400ms to 300ms. Proportionally, decrease the following block parameters: transaction limit, proposal gas limit and proposal byte limit. Proportionally, also decrease the block reward. Specification We propose the following changes to the chain parameters on the consensus client: Chain Parameters Chain Parameter Current Value Proposed Value vote_pace (ms) 400 300 tx_limit 5,000 3,750 proposal_gas_limit 200,000,000 150,000,000 proposal_byte_limit 2,000,000 1,500,000 We also propose the following change to the staking parameters, to roughly account for the more frequent block times: Staking Parameters Staking Para...
-
Operator perspective from Sydney AU on the 300 ms target. The pace reduction tightens the BFT quorum window proportionally for all geographies. Round-trip times from APAC/Oceania to the network’s EU/US centroid sit in 200-260 ms (Sydney → Frankfurt ≈ 250 ms, Sydney → US East ≈ 213 ms on our paths). At 400 ms vote pace, this leaves roughly 150-200 ms of slack for vote aggregation + propagation — comfortable. At 300 ms, slack falls to 50-100 ms, which is borderline for normal routing variance and packet-loss tails. Two concrete concerns: - Higher expected leader-timeout rate for non-EU/US validators, which works against the geographic decentralization the active-set increase (MIP-9) is encouraging. A useful empirical input before accepting: current p99 leader-round latency by geography at 400 ms. If APAC/Oceania p99 is already approaching ~280 ms today, the 300 ms target would syste...
-
MIP-12 — additional APAC operator perspective (Japan testnet full-node) Adding to @ShadowOfTime1 ’s Sydney AU perspective above with empirical data from a Japan bare-metal testnet full-node ( Monad Sentinel by Proofline ). Japan latency profile Direct TCP-connect RTT, median of 5 samples per endpoint, taken 2026-06-08 (spot check, not historical): - Japan → testnet-rpc.monad.xyz (QuickNode, likely APAC edge): ~70 ms - Japan → Frankfurt (Hetzner): ~243 ms - Japan → US East (Amazon): ~237 ms In the same range as ShadowOfTime1’s Sydney numbers. APAC operators broadly see ~200-280 ms to EU and US validator clusters. Observed consensus latency at 400 ms vote pace Aggregated from a dedicated monitoring host that has been scraping the Japan node’s otelcol metrics over a private tunnel since 2026-05-28. The 7 d window straddles our v0.14.4 → v0.14.5 upgrade on 2026-06-04 (two...
-
Sydney AU testnet validator — corroborating snapshot @ColinkaMalinka thanks for the Japan numbers — they line up closely with what we see from Sydney on the same v0.14.5 release. For transparency: unlike your dedicated 7-day Prometheus tunnel, we don’t yet have local time-series storage on the Sydney side — we push to the Foundation OTEL endpoint but read back only the current rolling window from our local otelcol exporter. Numbers below are a point-in-time snapshot averaged across 3 readings 60 s apart (variance ≤5 ms on the percentiles). Sydney testnet (val_id 267), 19 h since v0.14.5 restart Metric Value vote_delay_ready_after_timer_start_p50_ms (5min rolling) 105–110 ms vote_delay_ready_after_timer_start_p90_ms 140–145 ms vote_delay_ready_after_timer_start_p99_ms 240–245 ms raptorcast_udp_primary_broadcast_latency_p99_ms (30s rolling) 141–202 ms Timeout-cert f...
-
Thank you for sharing the data points and concerns @ShadowOfTime1 @ColinkaMalinka Vote pace is a minimum spacing between votes, not a deadline a vote has to beat. The parameter that triggers a timeout is the round timer, which is 3 * delta + vote_pace + local_processing . With today’s 100ms delta and 100ms processing estimate that’s 800ms at a 400ms vote pace and 700ms at 300ms — so the round timer does come down by 100ms. But that 100ms isn’t lost headroom. vote_pace sits in two places that move together: it’s the floor on when you release your vote, and it’s a term in the round timer (the deadline). Drop it by 100ms and both your vote-release and the deadline shift 100ms earlier, so the window left for transmission and processing stays put at 3 * delta + local_processing = 400ms Practically, validators near the geo center finish rounds faster because the floor drops to 300ms, a...