Roger Wattenhofer and Quentin Kniep propose speeding Solana’s block production by scheduling nearby validators consecutively. Their plan relies on self-reported locations, bringing an unverifiable physical input into the order of block producers. Each scheduled turn at block production is called a leader window.
The aim is to make fast handovers less dependent on operating near Solana’s biggest stake centers. The authors’ simulation cuts the mean handover delay between honest validators from 36.2 milliseconds to 17.0 milliseconds without giving any validator more leader windows. Reordering also changes the continuity of control: three-window groups can combine into longer consecutive stretches.
Wattenhofer, Anza’s head of research and an ETH Zurich professor, coauthored the geographic schedule with Kniep, who identifies himself as a researcher at Anza and ETH Zurich. Their SIMD-0675 draft makes that tension explicit, recording six adversarial windows in succession under its proposed three-window setting.
Both the scheduling proposal and its companion location-registration proposal were introduced as pull requests on Sept. 29. As of Oct. 7, they remain open. These are proposed rules and modeled outcomes, rather than results from a deployed geographic schedule.
Geographic order for the same allocations
Under the design, Solana would first calculate its stake-weighted random leader schedule as usual. A second pass would rearrange those leader windows into small groups, called bins, using reported geographic proximity.
A leader is the validator assigned to build blocks during a window. Every validator would retain exactly the number of windows it received in the original schedule; the change concerns when those opportunities arrive and which leader precedes them.
That predecessor matters under Alpenglow’s fast leader handover, where the previous leader sends its block directly to the next one. The authors argue that a random schedule favors validators near large concentrations of stake: they are more likely to be close to the leader they follow, while remote validators more often face a long hop.
Grouping nearby leaders seeks to give validators outside those centers more local handovers. The intended decentralization benefit is therefore an incentive to operate away from existing hubs, rather than a redistribution of stake or additional leader allocations. The simulations measure scheduling and latency, leaving actual operator relocation and stake concentration outside their results.
The draft pairs a three-window bin size with a 10% stake floor. That floor defines how widely a validator’s neighborhood must extend to reach enough stake. A densely populated location gets a smaller radius; a sparse one needs a larger radius. The floor covers active stake with valid reported locations. A completed bin can contain less than 10% of stake and repeated windows from the same operator.
The run-length simulation uses the mainnet stake distribution from epoch 1038, with 661 validators whose locations were corrected using Globalping measurements. Each simulated epoch contains 108,000 leader windows, and the results average five random seeds.
Geographic distance determines bin membership. To evaluate handover speed, the model maps validators to the nearest RIPE Atlas metropolitan area and estimates one-way latency as half the median round-trip time between those areas. Handovers within one metro are priced at zero.
With the random schedule, the mean delay between honest validators is 36.2 milliseconds. With three-window bins, it is 17.0 milliseconds. The median across all handovers, a different population, falls from 23.4 milliseconds to 4.5 milliseconds.
Those results support a substantial modeled reduction in transfer delay. Slot duration and transaction finality measure different intervals from the modeled transfer delay. The zero-delay assumption within metros also simplifies the network conditions validators actually face.
There is a broader reason to treat geography as a useful but imperfect shortcut. An August study published by the Solana Foundation associated greater distance with handoff penalties, while warning that it had not identified distance as the cause. Routing, peering and validator infrastructure remained unobserved.
Consecutive control and location incentives
The security trade-off appears in the same simulation. Its adversary holds 5% of total stake and sits in Sydney, with no other validator in Oceania. The authors describe this isolated placement as close to a worst case because the attacker can fill bins alone.
That example matters alongside the 10% stake floor. The floor governs neighborhood construction; the isolated 5% attacker illustrates how actual control of a bin can differ from that radius threshold.
An attacker leading the next bin can continue its control across the boundary. At the proposed setting, the longest adversarial sequence observed was six windows, consisting of two bins back to back. The design permits adjacent bins to extend consecutive control beyond the configured bin size.
The draft acknowledges that regional power, network or jurisdictional disruption could now affect consecutive leaders, producing longer skipped-slot sequences than a fully random schedule. It also identifies the possibility of more effective regional censorship during a run.
Using the draft’s assumptions of four slots per leader window and 200-millisecond slots, a three-window bin ideally spans 2.4 seconds. That figure describes one bin under the stated timing assumptions; regional exposure can cross bin boundaries.
The authors recognize a further speed-versus-security choice. An alternative added on Oct. 2 would arrange leaders along a shortest geographic path within each bin. The draft does not adopt it, explaining that it would weaken randomized schedule symmetry and make adjacent slots more predictable for co-located adversarial validators.
The companion SIMD-0674 specification would place self-reported coordinates in validators’ vote accounts. Signed updates establish who authorized a registration, and a geometric check establishes that the reported point lies near Earth’s surface. The machine’s actual location remains outside those checks.
SIMD-0675 relies on an economic argument: reporting a distant location will often put a validator behind leaders that are farther from its real machine, making its own handovers slower.
The authors test that argument by taking the largest validator in each of ten cities, leaving it physically in place and changing its registered city. The modeled Ashburn validator reduces its mean handover delay from 23.7 milliseconds to 21.0 milliseconds by claiming São Paulo, a reported improvement of 2.7 ± 0.2 milliseconds.
The authors report no other non-equivalent lie gaining more than 0.3 milliseconds.
The experiment also forms neighborhoods and bins using RIPE Atlas latency, whereas the proposed schedule uses geographic distance. Its individual-validator incentive results leave coordinated malicious location reporting and its effects on consecutive control unresolved.
False reporting often hurts the sampled validator’s speed, but the Ashburn exception limits the case for trusting physical location through economic incentives alone.
Timing compensation and the review ahead
Another number in the proposal can obscure the speed claim. SIMD-0675 would raise HANDOVER_COMPENSATION from 25 milliseconds to 50 milliseconds, even as transfer delays fall.
The separate compensation proposal accounts for optimistic block production already performed before ParentReady, the protocol event that starts the counted production timer. Compensation subtracts time from the first slot’s production budget after that event and shifts leader-window timeouts earlier. It is a timing adjustment, rather than validator pay.
The geographic simulation increases the interval from receiving the previous leader’s block to ParentReady from 23.2 milliseconds to 46.2 milliseconds. This separate interval accounts for the larger compensation value even as transfer delay falls.
The scheduling pull request currently shows no reviews. The location-registration pull request received buffalojoec’s approval on Oct. 5, with a caveat about potentially separating vote-account layout changes, but remains open. The Foundation’s Oct. 1 changelog likewise calls both changes proposed while listing Alpenglow under Devnet feature gates.
The schedule itself is consensus-critical and would require a feature gate; the draft still leaves its feature key and tracking issues unfilled. Its proposed transition would use the new algorithm from two epochs after activation.
The review question is whether the modeled reduction in delay and co-location advantage justifies the changed continuity of block production.
