# 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:** 9\ **Page:** 1
**Author:** ![bamrith](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/bamrith/32/375_2.png) [@bamrith](https://forum.monad.xyz/u/bamrith)\ **Post date:** [June 4, 2026, 9:22pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/1 "2026-06-04T21:22:18Z")
| 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 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. [MIP 12 - Decrease Vote Pace](https://mips.monad.xyz/MIPs//MIP-12) ---
**Author:** ![ShadowOfTime1](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/shadowoftime1/32/349_2.png) [@ShadowOfTime1](https://forum.monad.xyz/u/ShadowOfTime1)\ **Post date:** [June 8, 2026, 6:08am UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/2 "2026-06-08T06:08:07Z")
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: 1. 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 systematically exclude these operators. 2. Raptorcast propagation needs to complete within the same window. A 25% smaller window means proportionally more pressure on the multicast tree to converge under load. The block reward decrease is proportional and net throughput is preserved — but missed-slot rate is not necessarily proportional, so geographically distant operators may experience a net reward decrease beyond the per-block adjustment. Happy to share latency numbers from our Sydney validator if useful. ---
**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. ---
**Author:** ![ShadowOfTime1](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/shadowoftime1/32/349_2.png) [@ShadowOfTime1](https://forum.monad.xyz/u/ShadowOfTime1)\ **Post date:** [June 8, 2026, 4:18pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/4 "2026-06-08T16:18:21Z")
**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 fraction** (cumulative since process start, 19 h window): `enter_new_round_tc / (enter_new_round_tc + enter_new_round_qc) = 4293 / 171516 ≈ 2.50 %` Within 0.3 pp of the Japan 24 h figure (2.78 %). Two independent APAC operators on different latency profiles arriving at nearly the same TC rate is a meaningfully consistent signal, not a one-off. **Read against the 300 ms proposal** Our p99 vote-delay of 245 ms uses **61 % of the 400 ms budget today** and would use **82 % of a 300 ms budget** (~55 ms margin). @ColinkaMalinka’s Japan node sits at ~89 % (~34 ms margin). Both APAC samples land in the 80–90 % budget zone where the vote-aggregation tail starts to matter — and our TC fraction has been stable at 2.5 % specifically because the current 400 ms accommodates that tail. **+1 on the same ask** Strongly seconding the request for the Foundation to publish current p99 leader-round latency by geography at 400 ms before MIP-12 is locked. Two APAC data points now (Sydney, Japan); a network-wide geo breakdown will tell whether the 300 ms target stays inclusive for the operator distribution MIP-9 (active-set 200 → 250) is encouraging. Happy to share raw OTEL output if useful. ---
**Author:** ![michael-yxchen](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/michael-yxchen/32/37_2.png) [@michael-yxchen](https://forum.monad.xyz/u/michael-yxchen)\ **Post date:** [June 15, 2026, 7:07pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/5 "2026-06-15T19:07:57Z")
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, and a validator whose vote is ready within that 300ms floor keeps exactly the same budget. Round timeouts will not happen more frequently ---
**Author:** ![ShadowOfTime1](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/shadowoftime1/32/349_2.png) [@ShadowOfTime1](https://forum.monad.xyz/u/ShadowOfTime1)\ **Post date:** [June 16, 2026, 4:31am UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/6 "2026-06-16T04:31:23Z")
Thanks @michael-yxchen — that’s the correction we needed; our “% of budget” framing treated the floor as a deadline, which it isn’t. Since vote\_pace sits in both the release floor and the round timer, the transmission + aggregation window stays at 3·delta + local\_processing = 400ms for any vote ready within the floor. Our numbers actually land there: Sydney readiness p99 is 240–245ms and Japan’s 266ms, both under the 300ms floor, so the budget is unchanged for us — 300ms reads as safe from the APAC vantage. The only residual is the tail that crosses the floor (300ms \< readiness ≤ 400ms), which for us is sub-1%. That just sharpens the geo ask to one number: P(vote\_delay\_ready \> 300ms) by region. If that’s small everywhere, MIP-12 looks clean. ---
**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 16, 2026, 7:19am UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/7 "2026-06-16T07:19:34Z")
Thanks @michael-yxchen, that correction lands and it fixes our framing too. Our post above implicitly treated the 300ms floor as a budget the vote has to beat, which it isn’t. Since vote\_pace sits in both the release floor and the round timer, the transmission + aggregation window stays at `3 * delta + local_processing` regardless of pace. Agreed the question reduces to P(vote\_delay\_ready \> 300ms) by region. **Bottom line up front:** from Japan, 300ms looks safe. Our node stays inside budget the overwhelming majority of the time, and MIP-12 does not put us at risk of falling behind. The one nuance worth surfacing is a small, recurring tail, detailed below. Measurement caveat: the node exposes `vote_delay_ready_after_timer_start` only as p50/p90/p99 gauges, not a histogram, so an exact P(\>300ms) isn’t directly available from either of our setups. The closest honest proxy is the distribution of those percentiles over time. From our Japan full-node, 7-day window (v0.14.5, 30-min resolution, 336 points): | **percentile** | **min** | **median** | **max** | **share of windows \> 300ms** | | --- | --- | --- | --- | --- | | p50 (median vote) | 80 | 120 | 235 | 0% | | p90 | 144 | 204 | 341 | 5.7% | | p99 (slowest 1%) | 205 | 280 | 474 | 26.8% | How to read the last column: it is the share of 30-min windows in which that percentile exceeded 300ms, not the share of votes. So “p99 \> 300ms in 27% of windows” means that during about a quarter of the week the slowest ~1% of our votes crossed 300ms. Across all votes that is a fraction of a percent, and the median vote (p50) never approaches the floor. So in practice: the typical and even the 90th-percentile vote sit comfortably under 300ms, and only the extreme tail occasionally crosses it during network-variance spikes. That is not a liveness concern for us, the node does not drop out or get penalized over it. For MIP-12 the conclusion holds from our side: 300ms looks fine from Japan. We only added the time-variance detail for completeness, in case the APAC tail is useful context. Happy to share more of our data anytime it helps. ---
**Author:** ![mav3rick](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@mav3rick](https://forum.monad.xyz/u/mav3rick)\ **Post date:** [August 26, 2026, 5:43pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/8 "2026-08-26T17:43:37Z")
## MIP-12 — North America data point (Montreal testnet node) Since the 300 ms discussion so far rests on Japan, here is the same measurement from the other side of the world. Same caveat as ColinkaMalinka’s node: this is a testnet node outside the active set, and the gauge is only p50/p90/p99 over a 5-minute rolling window, so what follows is the share of windows whose quantile crossed the line, not a real P(delay \> 300 ms). One release only, v0.16.0, 7–26 Aug, 5,516 windows, no gaps. I kept the versions apart deliberately — folding our 0.15.x history into the same series pulled p99 exceedance from 96 % down to 82 %, and that is the release changing, not the network. | gauge | range | median | over 300 ms | | --- | --- | --- | --- | | p50 | 65–150 ms | 125 ms | 0.00 % | | p90 | 176–266 ms | 236 ms | 0.00 % | | p99 | 251–425 ms | 320 ms | 96.1 % | The interesting part is that the shape differs from Japan rather than just the magnitude. Our body is tighter — p90 did not cross 300 ms once in 5,516 windows, against 5.7 % there. But our p99 sits above the line 96.1 % of the time, against 26.8 %. So this is not a noisier location; it is a location with a higher floor, and calm network conditions do not move it. Sweeping the threshold on the same data: p99 exceeded 300 ms in 96.1 % of windows, 325 ms in 10.1 %, 350 ms in 0.49 %, 375 ms in 0.02 %. The 99th percentile of the p99 gauge is 340 ms. Put differently, 350 ms from Montreal buys about the margin that 300 ms buys from Tokyo. michael-yxchen’s correction upthread is what makes me unsure how to read this, so I would rather ask than assert. If vote pace is minimum spacing rather than a deadline, what actually happens to a node whose readiness sits structurally above the pace? From Japan the picture is a tail that occasionally crosses during variance, which reads as harmless. From here it is not a tail event at all — 320 ms is the steady state. Those feel like different regimes to me, and I cannot tell from the MIP whether the second one costs anything. The reason I care is geography. A floor calibrated from one vantage point ends up encoding that vantage point’s network position, and operators cannot tune their way out of the speed of light. If being structurally above the pace turns out to cost anything at all, the rational move is to relocate towards wherever the stake already is, which concentrates validators into shared transit, shared power and shared jurisdiction. Both measurements in this thread are OVH nodes, which is already a hint in that direction. I would not want a decision resting on our numbers without someone inside the active set confirming the same shape from this region — proposal delivery may well look different for a non-voting node, and neither data point here is in consensus. Happy to share the raw series, widen the window, or add a European vantage point if that helps. A histogram export for this metric would let all of us answer the actual question rather than approximate it with three gauges. ---
**Author:** ![michael-yxchen](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/michael-yxchen/32/37_2.png) [@michael-yxchen](https://forum.monad.xyz/u/michael-yxchen)\ **Post date:** [August 28, 2026, 6:40pm UTC](https://forum.monad.xyz/t/mip-12-decrease-vote-pace/488/9 "2026-08-28T18:40:18Z")
> If vote pace is minimum spacing rather than a deadline, what actually happens to a node whose readiness sits structurally above the pace? The network waits the full round timeout of 700ms to receive the proposal, before timing out the round. When the node structurally complete its round in 300ms, the networking waits, which is partially why the average block time is sitting above 300ms. This guarantees that a slower validator still gets a fair opportunity to propose