# MIP 12 - Decrease Vote Pace **URL:** \ **Category:** MIPs\ **Created:** [June 4, 2026, 9:22pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488 "2026-06-04T21:22:18Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![ColinkaMalinka](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/colinkamalinka/32/380_2.png) [@ColinkaMalinka](https://forum.monad.xyz/u/ColinkaMalinka)\ **Post date:** [June 8, 2026, 3:17pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/3 "2026-06-08T15:17:48Z")
# 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](https://prooflines.org/monad/sentinel) ). ## 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 distinct `service_version` series); avg/max are aggregated across both. Restart artifacts can inflate the single-sample max. `monad_state_vote_delay_ready_after_timer_start_p99_ms`: | window | avg | max | | --- | --- | --- | | last 1 h | 257 ms | 319 ms | | last 24 h | 266 ms | 549 ms | | last 7 d | 275 ms | 549 ms | `monad_bft_raptorcast_udp_secondary_broadcast_latency_p99_ms`: | window | avg | max | | --- | --- | --- | | last 1 h | 235 ms | 263 ms | | last 24 h | 226 ms | 305 ms | | last 7 d | 209 ms | 322 ms | Timeout-cert round fraction (`enter_new_round_tc / (enter_new_round_tc + enter_new_round_qc)`): | window | TC fraction | | --- | --- | | last 1 h | 2.46 % | | last 6 h | 2.33 % | | last 24 h | 2.78 % | `block_difference` vs `testnet-rpc.monad.xyz` reference, from our local sentinel history (6 h window, 1276 samples at 3 s cadence): median **−0.79** blocks, range **−2 to 0**. ## Read against the 300 ms proposal At the current 400 ms vote pace, our 24 h-average vote-delay p99 of 266 ms already uses **67 % of the budget**. Raptorcast secondary p99 averages 226 ms over 24 h (57 % of budget). The 24 h max for vote-delay p99 hit **549 ms** and for raptorcast secondary p99 **305 ms**. Both exceed the proposed 300 ms vote-pace target. The 549 ms is a single spike near our `v0.14.5` restart, so treat it as worst-case-observed rather than typical; but even the 24 h-average of 266 ms would consume **89 % of a 300 ms budget** , leaving ~34 ms of margin for the vote-aggregation tail. Concretely: at 400 ms today we already see ~2.5 % timeout-cert rounds (rate aggregated over last 1-24 h). If the margin shrinks 3-4x, that rate should climb materially, and disproportionately for geographically distant validators whose contribution to each round is more likely to arrive in the tail. ## Same ask as ShadowOfTime1 +1 on requesting the Foundation publish current `p99 leader-round latency by geography at 400 ms` before MIP-12 hard-forks the parameter. The Japan numbers above are one data point; a network-wide geo-breakdown would tell whether the 300 ms target is broadly safe or whether it systematically excludes APAC/Oceania operators, which would push back against the geographic-decentralization direction MIP-9 (active-set 200 → 250) is encouraging. Happy to share the raw time series or any specific OTEL metric from our Japan node on request. --- _[View the full topic](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488)._