MIP 12 - Decrease Vote Pace

MIPs
1
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

7 Likes
2

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.

3

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

4

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.

5

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

6

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.

1 Like
7

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.

1 Like