At epoch 1038, the simulation behind Solana's geographic scheduling proposal ran against 661 validators. Under the existing stake-weighted random schedule, the median leader handoff cost 23.4 milliseconds. Under SIMD-0675, that median collapses to 4.5. The average falls from 36.2 ms to 17.0 ms — a 53% cut on paper. Those numbers are the entire argument, and they rest on a single line in the model: intra-metro handoffs are priced at zero. Not small. Zero. When I first read the simulation methodology, that assumption was doing more work than any cryptographic claim in the draft, because the whole performance case stands on it — and it is physically impossible.
Solana does not let validators produce blocks whenever they like. Each epoch, the network computes a stake-weighted schedule that assigns every validator a contiguous run of slots — a leader window — and the protocol expects blocks in that order. For years that ordering has been deliberately blind to geography. A validator in Frankfurt can be scheduled immediately after one in Singapore, and the network absorbs the cost as a long hop in the handoff.
That randomness is not an oversight. It is a trust-minimization choice: the schedule derives from stake and a verifiable random function, so no operator can claim an advantage by lying about where it sits. The trade-off surfaces as latency, and latency is where Solana's narrative lives or dies.
Solana's slot time is nominally 400 milliseconds, and a leader window is measured in slots. Every millisecond between the end of one window and the first usable block of the next is a millisecond the network spends idle, and the accumulated idle time is what SIMD-0675 targets. The proposal is, in effect, a latency-recovery scheme: it does not make any individual block faster, it makes the gaps between leaders shorter by choosing leaders that sit closer together.
SIMD-0675, submitted by Roger Wattenhofer and Quentin Kniep — Wattenhofer runs research at Anza and teaches at ETH Zurich; Kniep is an Anza and ETH researcher — does not touch consensus. It leaves the validator set, the stake weights, and the number of windows each validator receives exactly as they are. What it changes is adjacency: who hands off to whom. It is a two-step scheduler. Step one is unchanged — compute the stake-weighted random leader schedule. Step two is new — re-sort those leader windows into small groups called bins, using reported geographic proximity, so that neighbors in physical space become neighbors in slot order.
The payoff logic leans on Alpenglow, Solana's in-progress consensus overhaul, which introduces direct leader-to-leader handoff: the previous leader sends its block straight to the next. Once handoff is direct, the physical distance between consecutive leaders becomes the dominant term in latency. That is the gap SIMD-0675 is built to close. Both the scheduling proposal and a companion location registry — which would turn self-reported positions into a usable ordering input — were filed and left open as pull requests as of October 7. Neither is deployed.
The mechanism is cleaner than it sounds, and the cleanliness is exactly what makes the failure modes legible. Under the proposal, each validator keeps its precise window count; the change is only when a window arrives and who precedes it. The scheduler bins validators by reported location, then orders windows within and across bins to shorten handoff distance. The draft sets a nominal 10% stake floor per bin — an apparent guardrail against any single operator dominating a group.
That floor does not do what it looks like it does. The draft is explicit: a completed bin may contain less than 10% of stake, and may include duplicate windows from the same operator. The floor governs neighborhood radius, not actual control. Once you read that clause, the safety story stops being a constraint and becomes a heuristic. A nominal 10% floor that the construction algorithm is permitted to undershoot is not a floor; it is a target the builder is encouraged to miss whenever geography makes it convenient. This is where my audit habits keep pulling me back to the simulation — the guardrail and the reality are allowed to diverge by design, and the divergence is precisely where adversarial stake hides.
The Sydney case makes this concrete. In the simulation, a single attacker node holding 5% of stake, isolated in Oceania with no other validators nearby, filled entire bins by itself. The authors call it close to a worst case. It is worse than that — it is a structural one. The 10% floor cannot defend against an isolated operator because the floor manages proximity, and an operator with no neighbors has no proximity to violate. Isolation is the attack. A geography-aware scheduler hands a lone operator in an empty region the same control it would deny a crowded one, without any faulty behavior on the attacker's part. It simply exists in a place the map left blank.
The adversarial sequencing compounds it. SIMD-0675's own draft records six consecutive adversarial windows under the three-window configuration, assembled from two back-to-back bins. The design explicitly permits adjacent bins to extend continuous control beyond the configured bin size. This is the signature failure of geographic scheduling: the nominal safety boundary — roughly 2.4 seconds across a three-window bin — is not the real worst-case control duration, because control does not respect the boundary you drew. This is finding the edge case in the consensus mechanism, and the edge case is the seam. When I modeled state-channel settlement race conditions in 2017, the same pattern appeared: the invariant held inside the unit and failed between units. Bins are units. Attackers live between them.
Then there is the latency number itself. The 17.0 ms average is systematically optimistic because the simulation assigns zero cost to intra-metro handoffs and treats "same metro" as "ideal neighbor." Real intra-metro latency is never zero — single-digit milliseconds on a good day, far more when routing misbehaves. The absolute figures are therefore inflated in the proposal's favor. The relative improvement, roughly half, is probably closer to reality, but even that is unproven. This is the difference between a benchmark and a marketing number: one has been measured against a hostile environment, the other against an assumption.
The draft has not converged. A second alternative was added to the discussion on October 2, and its mere existence signals the design is still in flux — the authors are iterating on the scheduler rather than defending a frozen specification. Proposals that grow replacement mechanisms this early are usually telling you the first mechanism has a hole the authors have not yet closed in prose.
The location input is the load-bearing element, and it is the one the network cannot check. Position is corrected in the simulation using Globalping, and metro mapping relies on RIPE Atlas — both external measurement systems sitting outside Solana's trust boundary. The proposal must convert "self-reported location" into "trusted neighbor relation," and nothing on-chain can perform that conversion. The location registry is the companion PR precisely because the scheduler is inert without it, and it is also the harder problem, because it must answer a question the draft concedes is open: how do you stop a validator from lying about where it is? Composability is a double-edged sword for security, and here the two composed pieces are a scheduler and a location oracle that cannot be trusted on its own.
That dependency has a cost the draft does not fully price. RIPE Atlas and Globalping are not Solana components; they are third-party measurement networks with their own operators, incentives, and failure modes. Threading them into block ordering extends Solana's trust surface outward to systems the protocol does not govern and cannot audit. The registry is, in this sense, a bridge — and the layer two bridge is just a pessimistic oracle, which is to say it assumes the worst about a counterparty it cannot verify. Here the counterparty is a validator's own description of where it stands.
There is one more gap, and it is the most important one. The proposal's secondary selling point is a decentralization dividend: by making local handoffs faster, it hopes to incentivize operators to migrate away from existing hubs. That is a real mechanism — economics steering geography. But the authors admit the simulation measures only scheduling and latency. It does not measure whether operators actually migrate, and it does not measure stake concentration. The decentralization benefit is the proposal's headline virtue and the one variable it never tests. A scheduler that rewards geographic spread is not a network that achieves it; the first is a rule, the second is an outcome, and the draft only ships the rule.
Everyone is reading SIMD-0675 as a performance proposal. It is not. It is a trust proposal wearing a latency costume, and the tell is which number the draft is willing to defend and which it is not. The performance figures are estimates from a favorable model. The security caveats — six-window adversarial sequences, boundary-crossing control, isolated-stake bins, regional outages that could produce what the draft calls "more effective regional censorship" — are written in as acknowledged limitations, not solved problems. The authors disclose the worst case because they know it is inherent, not incidental. That is technical honesty, and it is also an admission that the design's central risk cannot be engineered away from inside the design.
The deeper shift is what gets priced. Once ordering depends on location, location becomes an asset. Validators acquire an incentive to misreport position to win better adjacency, and well-capitalized operators that can afford multi-region deployments plus precise positioning will extract more from the new rules than small validators can. A proposal built to spread the network geographically may instead reward those best able to game the map. Position spoofing becomes a yield strategy, and the network holds no cryptographic instrument to detect it.
The question is not whether SIMD-0675 makes Solana faster. In simulation, it does. The question is whether a network that spent years minimizing trust in its own schedule is willing to reintroduce a trusted off-chain input to buy back milliseconds — and whether it can measure the decentralization it promises before it ships the rule that assumes it. Watch the location registry, not the scheduler. If that PR cannot answer how a validator's position is verified, the performance number will never matter, because the ordering will already be for sale.