Invest1 publisher2 min readPublished
Anza's Solana scheduling plan makes an on-chain location the condition for producing blocks
Anza researchers' SIMD-0675 would schedule Solana validators by registered location, cutting simulated handover delays 53%, to 17.0 milliseconds. Every validator would keep its share of slots, so what operators pay for faster handovers is disclosure of where their machines run.
The Investor · Invest desk
What happened
- Anza researchers Quentin Kniep and Roger Wattenhofer wrote the plan as two Solana Improvement Documents, SIMD-0674 and SIMD-0675, both opened around 29 September 2026.
- The schedule would sort validators into geographic bins that run back to back, with at most three consecutive leaders per bin and about 2.4 seconds per regional run.
- Anza's simulation ran on Solana mainnet data from epoch 1038, covering 661 validators.
- SIMD-0675 moved to ready-for-review status at 14:27 UTC on 30 September 2026, while SIMD-0674 is still a draft.
Compiled by The InvestorSomething wrong?How this is made
Why it matters
- constraint An operator that declines to register loses voting as well as block production, so a validator that wants to keep its site private has no partial option.
- exposure Registered locations would sit on-chain for every participating validator, giving anyone who reads the chain a map of where Solana's block producers operate.
- decision Solana's reviewers are weighing roughly 13% of Alpenglow's finality target against a disclosure rule that binds every validator.
According to Crypto Briefing's account of the simulation, the saving comes to 19.2 milliseconds a handover [1]. Today's random order averaged 36.2 milliseconds and the geo-aware schedule 17.0 [11]. The wait exists because an incoming leader needs the previous leader's work before it can build, and distance stretches it [12]. Alpenglow, the consensus protocol these proposals are tied to, aims for finality of around 150 milliseconds [10]. Measured against that target, the average handover shrinks from about 24% of the budget to about 11% [2].
The 17.0 figure still includes long hops. Each geographic bin is capped at three consecutive leaders [4], so at least one handover in every three passes to another bin [4], presumably over a greater distance.
On money, the design is narrow. According to the proposals, stake weights and slot allocations stay exactly the same, and only the timing of each validator's slots changes [6][7]. A validator in a crowded region gets no extra slots, and one in a remote region loses none. Location enters at a single point, eligibility, because a validator that declines to register one would be excluded from block production and voting [8]. By leaving slot allocation alone, the authors kept the proposal clear of any fight over who gets how many slots [6].
As written, then, location is a gate with no effect on slot share. It would become a revenue factor if the fees a slot earns depend on when it falls, since a region's run of about 2.4 seconds [4] would then earn more or less depending on when it lands. The simulation, as reported, measured handover latency and did not include validator income [11]. Location would also become a revenue factor if a revised spec tied allocation to region; the current text holds allocation fixed [6].
I think the gate reading is right on this evidence. Anza is asking operators for disclosure and offering, in return, about 19 milliseconds off each handover for the whole network [1]. That view fails if a later measurement shows fee income per slot tracking schedule position.
What to watch
- Review comments on SIMD-0675, especially whether the rule excluding validators that do not register a location survives intact.
- Whether SIMD-0674 moves out of draft, since the two documents together describe the location registry and the geo-aware schedule.
- Alpenglow's move through testnet and devnet, which began in late September 2026, and whether its finality results strengthen the case for cutting handover time.