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.