Anza has put forward SIMD-0675, a Solana Improvement Proposal that would schedule validators by geographic location. The proposal is now in the hands of the Solana community for review. If adopted, it would change how the network routes block production and could affect the makeup of the validator set.
What geographic scheduling would actually change
Solana validators currently operate under a setup that doesn't organize them by where they sit on the map. SIMD-0675 would sort validators into slots based on their physical location. Anza argues this could improve network efficiency, since nodes closer to each other can pass data back and forth with less delay. In a network built for speed, shaving off milliseconds at the validator layer is the kind of change that adds up across thousands of slots per day. The proposal doesn't spell out exact latency numbers in the public summary, but the efficiency case rests on the idea that geography shapes how fast information moves. Less distance, fewer hops, tighter timing.
The privacy problem that doesn't go away
There's a catch. Scheduling validators by location means the network has to know where those validators are. That's a departure from the default assumption that a validator's physical setup isn't part of the protocol's business. The proposal may raise privacy concerns, and it's not hard to see why. Validator operators often run infrastructure they'd rather not pin to a specific city or region. If geographic data becomes a scheduling input, that information has to live somewhere in the system. Who can see it, how it's stored, and whether it can be correlated with other data are questions the proposal doesn't fully answer on its own. For operators in jurisdictions where running blockchain infrastructure draws scrutiny, the trade-off between efficiency and exposure is a real one.
Validator participation is the other open question
SIMD-0675 could impact validator participation. Some operators may find geographic scheduling workable or even beneficial, especially those already clustered in well-connected regions. Others might see it as a reason to rethink their setup or step back. A validator that doesn't want to disclose its location, or that sits in a region with weaker connectivity, may end up at a disadvantage in the scheduling queue. That's not a hypothetical. Participation changes when the rules change, and this proposal changes the rules. The proposal doesn't guarantee that geographic scheduling leads to a more concentrated validator set or a more distributed one. It depends on how operators respond, and that's not something a specification can predict.
Where SIMD-0675 goes from here
SIMD-0675 is a proposal, not a live change. It's out for community consideration, which means the feedback period is where the real work happens. Validator operators, developers, and anyone with a stake in Solana's infrastructure have a chance to weigh in before anything moves forward. The efficiency argument will get tested against the privacy and participation concerns. If those concerns hold up under scrutiny, the proposal could be revised or shelved. If they don't, geographic scheduling could become part of how Solana validators are organized. There's no timeline attached to the proposal yet, and no signal about when or whether it might advance to a vote. For now, the document is public and the comment period is open.
