MIP-12

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...