Anza Researchers Propose a Geo-Aware Solana Leader Schedule in SIMD-0674 and SIMD-0675

Two Anza researchers, Quentin Kniep and head of research Roger Wattenhofer, have written up a way to change the order in which Solana validators take turns producing blocks, so that each leader tends to hand off to a validator physically near it. The design comes as a pair of Solana Improvement Documents opened on 29 September 2026: SIMD-0674 lets validators register their location on-chain, and SIMD-0675 uses those locations to build a geo-aware leader schedule. In a simulation on mainnet data, the authors report that mean leader handover latency falls by 53%. Both remain open proposals, and neither has been approved.

Kniep is listed first on both proposals, with Wattenhofer, who is head of research at Anza and a professor at ETH Zurich, as co-author. Wattenhofer said on X on 30 September that the geographic ordering had been suggested by others, and that he and Kniep "just wrote a SIMD how it could be done." SIMD-0675 was marked ready for review at 14:27 UTC on 30 September 2026. SIMD-0674 remains open, with its frontmatter status set to Draft.

Why the Solana leader schedule rewards co-location

Solana's leader schedule assigns block production for each epoch at random, weighted by stake. A validator with twice the stake gets roughly twice the slots, but the order is random, so a leader in Tokyo can be followed by one in Frankfurt and then one in São Paulo. Every handover has to cross that distance before the next leader can build on the previous block.

SIMD-0675 names the side effect directly. Validators near the network's center of stake are usually close to whoever led before them, so they see the previous block sooner. The authors write that this "rewards co-location and penalizes remote validators", and that the protocol should work against that centralization incentive.

The proposal argues that shorter handovers shrink "the advantage of being located at the gravity of the stake". It is written for Alpenglow, the new consensus protocol now running on Solana testnet, where every leader handover is a delay the next block has to absorb.

How SIMD-0675 reorders leaders by geography

SIMD-0675 keeps the existing stake-weighted random schedule and adds a post-processing step. The algorithm groups geographically close leaders into bins and places up to three of them in a row (RUN_LENGTH = 3). The proposal states that "every validator still receives exactly as many slots as before", so stake weighting is unchanged and only the order moves.

Two limits guard against abuse. A bin is only as tight as the distance that captures 10% of total stake (STAKE_FLOOR), roughly 44 million of the 440.3 million SOL staked across Solana's validators on 30 September 2026, because smaller bins would make it easier for a low-stake attacker to control whole runs. The cap of three leader windows also limits how long any one region leads in a row; the proposal puts a full run at about 2.4 seconds.

The authors' simulation on epoch 1038, with 661 mainnet validators, puts mean handover latency at 36.2 ms under today's random order and 17.0 ms under the geo-aware schedule. By the authors' count, a run length of three captures 74% of the gain available at a run length of eight. In adversarial simulations, runs longer than three appeared in 0.2% of cases, with the longest at six windows.

The change also doubles HANDOVER_COMPENSATION, a timing allowance defined in SIMD-0630, from 25 ms to 50 ms, a value the authors derived from simulation using real-world latency data.

What SIMD-0674 asks validators to register

SIMD-0674 adds a 12-byte location field to each vote account, stored as three 32-bit integer coordinates in meters from the center of the Earth. The proposal uses whole-number arithmetic throughout, with no floating point or trigonometry, so that every validator client, including Firedancer, computes a bit-identical schedule. The field fits inside the vote account's existing allocation, so no account resizing is needed.

Registration would not be optional. Once the feature activates, a validator without a registered location is, in the proposal's words, "treated as if it were not staked": it is excluded from the leader schedule and from voting, and its stake does not count toward consensus. That would apply to all 670 validators Solana Compass tracked on 30 September 2026. Location changes submitted during epoch e-1 take effect in the schedule for epoch e+1, the same delay as a stake change.

Locations are self-reported. SIMD-0674 states plainly that its validity check "verifies geometry, not actual location truthfulness", meaning a validator can register any point on the Earth's surface, and it leaves the problem of false reports to the schedule design. SIMD-0675's answer is incentive analysis: across ten tested cities, including Frankfurt, Ashburn, Tokyo and São Paulo, reporting the true location was the best strategy in nine, and "no other lie gains more than 0.3 ms."

RIPE Atlas and the latency estimates

The simulations draw on RIPE Atlas, a public network of measurement probes, for round-trip latency between cities. Asked on X on 30 September 2026 whether the design depended on it, Wattenhofer replied: "We DON'T use Ripe Atlas in the actual algorithm." He said the data is used for the performance estimates, adding: "If you have something better, please tell us."

That distinction matters for how far to trust the 53% figure. The algorithm itself only needs the coordinates validators register. The latency savings are an estimate built on third-party probe data, and real handover times will depend on where operators run their machines.

What SIMD-0674 and SIMD-0675 need before activation

Both pull requests carry the standard SIMD bot requirement: at least one approval from an Anza reviewer and at least one from a Firedancer reviewer before they can merge. Neither had any approvals as of 30 September 2026. That same two-client sign-off is what SIMD-0649 was waiting on when it closed without merging earlier in September.

SIMD-0675 also depends on SIMD-0180, which defines the base leader schedule, and on SIMD-0630, which sets handover compensation. Any activation would come through a feature gate after merge, and no timeline has been proposed.

For validator operators, the practical change is a new required step: registering a location, and deciding whether to report where the machine is. For the network, the proposal is a bet that ordering leaders by distance can make Alpenglow faster while reducing the pull toward a handful of data-center hubs.

Correction, 30 September 2026: An earlier version of this article, and our post on X, credited the proposals to Wattenhofer alone and described the idea as his. Kniep is the first-listed author of both, and Wattenhofer says the idea was suggested by others.