Geo-Distributed Jito Stake Delegation Process

Abstract
Jito Foundation can further bolster validator ecosystem health with a trivial reduction in overall yields. Please comment on the following proposal to introduce a new delegation set to the jitoSOL pool, redirecting 20% of stake to validators outside the current area of stake concentration. The proposal would join a longitude measure from stakenet/history with existing Stakenet Steward rankings to calculate the new delegations.

Motivation
Jito’s stake pool has been wildly successful in creating a high performance validator network with consistently high yields. There is now room to diversify its delegation strategy with trivial disruption to overall pool yields. Specifically:

  • Yields differ only 40bps from the top quintile to the fifth quintile (Discord).
  • Vote credits are even more impressive, with a spread of just 176 (287 minus 111) from rank 200 to 499 as of epoch 797 (Vortex | Validator Explorer).
  • Stakenet Yield Score goes from 99.97% to 99.25% between validator 201 and 495, and the validators behind these “lower” yield scores include stake as far away as Los Angeles and Singapore (see Steward and https://www.jito.network/stakenet/history/).

Secondly I had a chat with Brian and Aidan (sp?) at Accelerate and Jito remains open to changes to the Stakenet Delegation system, if the changes align with IBRL and validator economic health.

Key Terms

  • Stake center-of-mass (Stake CoM or CoM): The stake-weighted longitude of Solana validators, currently defined as all stake, not just that running the Jito-Solana client.
  • Longitude: Geographic longitude of validator’s IP address, defined by ipinfo.io
  • Latitude: same as above, but Latitude
  • Geo-Distributed: Outside of the current Stake CoM

Specification
Establish a new, secondary stake delegation policy as follows:

  1. 20% of the jitoSOL pool to 200 “geo-distributed” validators
  2. Exclude the validators in the current Stakenet delegation
  3. Location: 30° < Stake CoM Longitude < -30° (>2 timezones)
  4. Ordered by existing Stakenet ranking system

Details

#1 Take 20% of the jitoSOL pool. jitoSOL will soon reach 20M SOL! At 20% of this, our new set of 200 validators would be delegated 20,000 SOL each. This gives them a high probability of survival, especially if matched by SFDP. With jitoSOL gaining so much market share, reducing the existing high performance/yield set by 20% brings them back to the 80,000 from less than a year ago.

The 201-500th ranked validators’ hard work is nearly indistinguishable from the top 200 by the metrics discussed in “Motivation” above. Further, this would significantly rejuvinate validators 501-1200 who have become despondent when discussing a possible Jito delegation.

Increasing the validator set by 100% dramatically increases Jito’s impact with a trivial dip in overall pool yields. This will also mitigate the force of stake centralization, which would marginally decrease Solana’s reliance on, currently, EU datacenters and supply chains.

#2 Exclude validators from existing set. Obviously, no doubling up.

#3 Greater than 30 degrees, or two timezones, from Stake CoM. This is the hard part as calculating it requires an external oracle. The Stakenet front-end uses ipinfo.io which has worked well for over 18 months now so this proposal suggests using that. Because StakeNet already captures IP address of each validator, this information is already on-chain with full history. Technical details below.

This proposal’s choice of distance from the stake CoM is arbitrary, as is not using latitude, though both should probably be discussed. The proposed “greater than +/- 30°” includes Brazil and 45° (three timezones) would not. Simplifying the calculations and data requirements by not using latitude is convenient and merely reflects the current global economy and Internet architecture, nothing more.

#4 Ranking System: to keep things simple, take the intersection of StakeNet ranks 201-N with all validators greater than 30 degrees outside the Stake CoM, and distribute 20% of the pool uniformly between the newly ranked top 200.

After seasoning this implementation, future proposals might introduce a weighting factor for overall distance. This would be too complicated for the current proposal and might also conflict with multiple leaders longer-term.

Stakenet Distribution (can it be done with minimal changes to code?)

Changes to Stakenet Steward (https://www.jito.network/stakenet/steward/)

  • Existing Pool Target Delegation ==> 0.40% from 0.50%
  • Longitude Pool Target Delegation = 0.01%

Engineering the calculation and storage of Stake Center of Mass

  • Geo with ipinfo.io solid for nearly 2 yrs
  • Outside StakeNet or calc’d on the fly okay?
  • [//TODO//]
  • Need technical help here

Benefits/Risks
Benefits described in-line above. In addition, because the stake CoM does not follow daylight hours, distributing stake beyond the CoM should improve marginal application performance for awake users by bringing local RPC hosts closer to leaders on average. (As I understand it, RPC providers are already distributed globally.)

Risks and Potential Complications:

  • The proposed mechanism is economically resistant to tampering because of the low likelihood validators in the top 200 will tank their performance to fall out of the existing set, as it will remain more lucrative and risks 30 epochs of poor returns. However this risk exists.
  • Estimated reduction of 5-15bp of pool yields
  • Requires changing Stakenet programs
  • May require adding lat/long to Stakenet on-chain
  • Relies on an off-chain process and oracle, and geo-coding validators has been fraught, historically
  • DoubleZero
  • Multiple leaders

Outcomes
Some 20% of Jito’s stake pool (4M SOL!) gets redistributed greater than 2 timezones away from the current CoM.

Cost Summary
TBD (The total cost of the proposal, broken down if needed.)

Performance Milestones, if applicable
TBD

2 Likes

I’m supportive of this proposal. However, based on the potential risks, I’d start with 10% of Jito’s stake pool (2M SOL).

My understanding Proof of Location is really hard?