CONSENSUS — Solana × SIMD-0675

Solana’s Geographic Leader Schedule: Splitting Stake Doesn’t Pay. Location Does.

10 min read
SolanaConsensusMEVRust

Under Alpenglow’s fast leader handover, the gap between two leaders is mostly the time a block takes to cross from one to the next. Today’s schedule picks leaders at random, so that crossing is often an ocean. SIMD-0675 proposes to reorder the schedule so that leaders near each other go one after another.

In review, Dean Little raised the obvious worry: that the reordering “appears to incentivize sybils”, letting validators use geography, “or even just a self-attestation of geography”, to line up their leader rotations “with better-than-random odds”. Two days later, the author of the proposal’s parameter analysis answered that splitting stake barely moves the odds, 7.146% to 7.147% in one example, because “the majority of the ‘upside’ for extractors (compared to random) is already given by the schedule design.”

We rebuilt the reordering in Rust from the specification to check both statements. The reviewer is right about splitting: it changes nothing, not even one window. But the second half of the sentence is the finding. The upside the schedule hands out depends on where an operator’s stake sits, and an honest operator in the right region gets back-to-back windows five to seven times as often as today, without splitting or lying about anything.


Bins, radii and runs

The base schedule is computed exactly as today, one stake-weighted random leader per four-slot window. SIMD-0675 then walks it in order and drops each leader into a bin:

  • Radius. Every validator has a radius, the smallest distance around it that holds STAKE_FLOOR (10%) of all stake. Dense places get small radii, isolated ones large radii. Locations are self-reported, through SIMD-0674.
  • Bins. A leader joins a random open bin whose anchor is within the larger of the two radii, or opens a new bin if none is.
  • Runs. When a bin holds RUN_LENGTH leaders, it is shuffled and written out as a block of consecutive windows. The proposal says 3; reviewers have argued for 7.

Every validator keeps exactly the windows it would have had. Only their order changes. With 200 ms slots, a run of three windows is 2.4 seconds of block production from one area of the map.

rustthe reorder, condensed from our model
for &l in base {
    let near: Vec<usize> = (0..bins.len())
        .filter(|&i| {
            let a = bins[i].anchor;
            dist2(&vs[l], &vs[a]) <= r[a].max(r[l])
        })
        .collect();
    let bi = if near.is_empty() {
        bins.push(Bin { anchor: l, members: vec![l] });
        bins.len() - 1
    } else {
        let i = near[rng.roll(near.len())]; // one roll per join
        bins[i].members.push(l);
        i
    };
    if bins[bi].members.len() == run_length {
        let mut b = bins.remove(bi);
        rng.shuffle(&mut b.members); // Fisher-Yates
        out.extend(b.members);
    }
}
// end of epoch: shuffle the open bins, shuffle each one, append

The model, and a check against the proposal

Our implementation follows the specification’s pseudocode line for line: the radius, the nearness test, one random draw per join, Fisher-Yates within a run and a shuffled flush at the end of the epoch. Two simplifications are deliberate. The random generator is SplitMix64 rather than the specified ChaCha20, which changes which schedule comes out but not its statistics. And the network is stylized: about 800 validators with lognormal stake across 19 metros. Asia holds 10.4% of stake, the figure in the parameter analysis published on solana.com; the European and North American split and the metro mix are our assumptions. Latency between leaders uses the analysis’ estimate, 1.5 times the great-circle distance at 200 km per millisecond. Each scenario is 108,000 windows, an epoch, averaged over five seeds.

Mean handover, random schedule (SIMD’s figure)37.3 ms (36.2)
RUN_LENGTH 318.2 ms (17.0)
RUN_LENGTH 711.6 ms (10.8)

The proposal’s simulation, on the real stake distribution of epoch 1038 and measured round-trip times, is in brackets. Our stylized network lands within about a millisecond at every run length, which is close enough to trust it for the question it was built for: who gets consecutive windows.


Splitting stake changes nothing

We gave one operator 3% of stake as one validator in Frankfurt, then as six validators of 0.5% each in the same place. The two schedules were identical, window for window, at every run length.

That is not a statistical tie, it is structural. The base schedule gives the six the same windows the one would have had. The radius of a location is computed from all the stake there, so it is the same. And a bin only ever asks about locations and radii, never identities. Sybils at one address are invisible to the reorder, which is the reviewer’s 7.146% to 7.147% taken to its limit.

Splitting across regions is worse than useless for an extractor. The same 3% spread over Frankfurt, Ashburn and Singapore led two windows in a row 4.2% of the time at RUN_LENGTH 3, against 7.6% for the operator that stayed in one place.


Location changes a lot

Consecutive windows under one operator are the precondition for multi-block MEV: two windows are eight slots in which one party orders every transaction. We measured how often an operator’s window is followed by another of its own, under today’s random schedule and under the reorder. Columns are random, then RUN_LENGTH 3, then 7.

1% operator, Frankfurt1.06% → 2.56% → 3.31%
1% operator, Tokyo1.06% → 5.31% → 7.66%
3% operator, Frankfurt3.15% → 7.56% → 9.22%
3% operator, Tokyo3.15% → 15.10% → 19.10%
3% split over three regions3.15% → 4.18% → 4.90%

Under random, the chance is the operator’s stake share, wherever it sits. Under the reorder, a run is filled from nearby stake, so the chance tracks the operator’s share of its region instead. Three percent of all stake is a modest slice of Europe and a large slice of Asia, the smallest region that still forms bins of its own at a 10% floor. The same operator in Tokyo gets back-to-back windows 4.8 times as often as today at RUN_LENGTH 3, and 6.1 times at 7, twice what it would get in Frankfurt.

Nobody lied and nobody split stake. This is the schedule working as designed, and it is the reviewer’s point stated with a location attached: the upside comes from the design, and the design pays most to the largest operator in the smallest self-contained region. The solana.com analysis already notes that Asia sits just above the floor, at 10.4%, “with very little margin”. Our numbers say the margin is also where consecutive control is cheapest.


And lying about it

The attack the proposal’s authors model is a validator that declares an isolated location, so that no one else joins its bins. The solana.com analysis uses the most isolated point it could find, in the South Pacific, and reports that at RUN_LENGTH 7 lying is worth 0.28 extra consecutive windows to a validator with 4.07% of stake, the largest today, and 1.69 to one with 10%.

4.07% operator, back-to-back, truthful in Frankfurt4.23% → 10.13% → 12.15%
4.07% operator, back-to-back, declares South Pacific4.23% → 32.34% → 41.59%
10% operator, back-to-back, truthful in Frankfurt10.05% → 21.72% → 25.98%
10% operator, back-to-back, declares South Pacific10.05% → 65.11% → 83.19%

Measured the analysis’ way, as the expected run remaining from one of the liar’s windows, our model puts the gain from lying, against the same operator in Frankfurt, at 0.58 windows for the 4.07% validator and 2.43 for the 10% one, both at RUN_LENGTH 7. That is higher than the analysis’ figures, which come from the real map, where a few validators in Argentina and Australia can still reach the isolated point. The direction is the same: lying pays a little below the floor and a lot at it, which is why STAKE_FLOOR is pinned at 10%.

The proposal’s own location-fibbing table shows lying rarely improves a validator’s latency. It was never meant to. The reason to lie is the run, not the handover.


What it means for the parameters

RUN_LENGTH moves every number above. Going from 3 to 7 buys 6.6 milliseconds of mean handover in our model and raises back-to-back control for every operator we measured. The proposal’s authors prefer 3 for exactly this reason; the analysis finds a knee at 7 and calls 3 “the conservative choice”. Reviewers suggested handling Sybils outside the protocol, by raising the validator admission ticket or by detecting misreported locations, and the authors agreed that detection is probably possible.

Neither remedy touches the effect in section 04. A ticket prices the number of validators, and the location-driven gain needs only one. Detection catches false locations, and the Tokyo operator’s location is true. If the concern is consecutive control by honest operators, the levers are the run length and the floor, and the floor is already pressed against Asia’s share.


What this does not show

The network is stylized, so the exact percentages belong to it; the mechanism, that consecutive control tracks local rather than global share, does not depend on the split we chose. Back-to-back windows are a precondition for multi-block MEV, not a measure of its value, which the analysis also stresses. The random generator differs from the specified one. And SIMD-0675 and SIMD-0674 are open proposals, last amended on 22 October, so the constants may still change.


Geo-Aware Leader Schedule: Questions People Actually Ask

What is Solana’s geo-aware leader schedule?

SIMD-0675, an open proposal, keeps today’s stake-weighted random leader schedule and then reorders it: leaders that are geographically close are grouped into runs of RUN_LENGTH consecutive leader windows, so the handover between them is short. Every validator keeps exactly as many windows as before.

Does splitting stake into several validators help under SIMD-0675?

Not at one location. The reorder sees a validator’s location and stake, not its identity, so six validators in one city with a combined stake behave exactly like one. In our model they produced identical schedules, window for window.

Where does the geo-aware schedule give an operator more consecutive windows?

Where its share of the local stake is large. A run is filled from nearby stake, so an operator’s chance of leading two windows in a row tracks its share of its region. In our model a 3% operator in Tokyo got back-to-back windows 15% of the time at RUN_LENGTH 3, against 3% under today’s random schedule and 7.6% in Frankfurt.

Can a validator lie about its location to get consecutive leader slots?

Yes, and the proposal’s parameter analysis measures it: a validator that declares an isolated location ends up alone in its bins. The analysis puts the gain at 0.28 extra consecutive windows for a 4.07% validator at RUN_LENGTH 7, rising sharply once the liar holds STAKE_FLOOR, 10% of stake, which is why STAKE_FLOOR sits at 10%.

Is SIMD-0675 live on mainnet?

No. As of 26 October 2026 it is an open proposal, as is SIMD-0674, the location registration it depends on. Its parameters, especially RUN_LENGTH, are still being debated between 3 and 7.


The one-line version

SIMD-0675 halves handover latency and does not reward Sybils, but it turns local stake share into consecutive leader windows, and the smallest region that forms its own bins is where a large operator gains the most.

The consensus this schedule feeds is in Alpenglow finality in numbers, the admission ticket reviewers proposed raising is in the 2,000 validator seats, and the stake-weighted QoS that follows the leader is in stake-weighted QoS, with the formula.

Sources: SIMD-0675 and SIMD-0674 as amended on 22 October 2026, with their review threads to 26 October; the parameter analysis on solana.com, by Umberto Natale, 14 October 2026. Results are from our Rust model of the reorder, described in section 02.

xroot.devOn-chain research, published in full
𝕏 @xrootdev
← Back to all notes