JIP-3: Transfer of Jito Stake Pool management to StakeNet (Protocol Development)

JIP - Official
1

1. JIP 3: Transfer of Jito Stake Pool management to StakeNet (Protocol Development)

2. Abstract

This Jito Improvement Proposal (JIP) seeks to transition the management of the Jito Stake Pool to StakeNet, a decentralized protocol developed by Jito Labs.

This transition aims to enhance the security, efficiency, and transparency of the Stake Pool management by leveraging StakeNet’s on-chain automation. The proposal lays out a staggered transition timeline to ensure protocol reliability and performance for the duration of the transition.

3. Motivation

Following the successful implementation of JIP-1, there is now an opportunity to more fully decentralize the Jito Stake Pool’s management processes.

Currently, the Jito Stake Pool validator set is adjusted with off-chain bots and manual oversight of on-chain data, which introduce potential security risks and operational inefficiencies. Transitioning to StakeNet will allow for:

  • Increased Transparency: All operations, such as churning validators in and out of the Stake Pool, become verifiable on-chain.
  • Enhanced Security: Reduces the risk associated with centralized control points.
  • Greater Efficiency: Automates stake allocations and adjustments, reducing manual intervention.
  • Community Governance: Allows for greater community involvement in decision-making processes.

The implementation of StakeNet will arguably make JitoSOL the most decentralized LST on any chain, and prepare the Jito Network for its next phase of growth.

4. Key Terms

StakeNet: A decentralized protocol developed by Jito Labs designed to manage staking processes on the Solana blockchain. StakeNet utilizes on-chain programs and off-chain keepers to autonomously manage Jito Stake Pool allocations based on predetermined criteria.

Stake Pool Validator Set: The group of validators responsible for receiving delegation from the Jito Network and maintaining the quality and returns of the underlying liquid staking token, JitoSOL.

Steward Program: The core component of StakeNet, acting as the automated “brain” of the protocol. It calculates validator scores, redistributes stakes, and adapts to network changes based on set parameters.

Phase Transition: The structured process of shifting management responsibilities from manual and offchain methods to StakeNet’s protocol. This process is divided into phases to ensure stability and security at each step.

5. Specification

Transition Plan

Phase 1 - Preparation - One Month:

During this phase, which coincides with the DAO’s 30-day discussion period, there will be a review period for the community as StakeNet’s code is finalized. An audit of StakeNet is currently underway, and the code has recently been open-sourced and can be reviewed here: stakenet/programs/steward at master · jito-foundation/stakenet · GitHub

Additionally, Jito Labs has open-sourced modeling concerning the hypothetical performance of StakeNet over the past 40 epochs. This data should allow validators ample time and sample size to review and begin preparing for StakeNet’s delegation parameters: StakeNet Historical Analysis - Google Sheets

Additionally, there will be an ongoing evaluation period during which Jito Labs will monitor StakeNet performance, but will not use StakeNet parameters to dictate live delegation. This monitoring process will be undertaken with a mock LST on Mainnet and performance data will be provided to the community.

Phase 2 - Partial Transition - Three To Six Months:

Because StakeNet is a first-of-its-kind protocol, Jito Labs will maintain control over upgradability and delegation parameters to ensure StakeNet is operating properly and to respond dynamically to any needed fine-tuning. During this period, inclusion parameters will be largely decided by DAO governance; however, Jito Labs will maintain emergency powers for an indefinite period, to be used only in extreme circumstances.

During this phase, Jito Labs will provide periodic updates regarding any program and configuration changes. Additionally, there will be a bug bounty program and audit results provided.

Phase 3 - Full Transition - Ongoing

Upon successful completion of Phase 2, Jito Labs will begin the process of transferring all management functions of the Jito Stake Pool to StakeNet Steward Program, decommissioning existing off-chain bots and manual processes.

After a to-be-determined period, all StakePool parameter authorities, including blacklist authority, will be transferred to the DAO.

6. Benefits/Risks

Benefits

  • Decentralization: By reducing the need for offchain and human processes, the transition to StakeNet will make JitoSOL a more fully decentralized LST compared to many of its peers.
  • Scalability: Enables the Jito Stake Pool to efficiently scale alongside the growth of the Solana ecosystem.
  • Community/Governance Driven: Facilitates a more community-oriented approach to pool governance and operations.

Risks

  • Implementation Risks: Potential bugs or issues during the transition phases could temporarily affect pool operations and performance.
  • Adaptation Period: The community and validators may require time to adapt to the new system, which could lead to friction for validators.

7. Outcomes

Successful passing of this proposal will provide Jito Labs with the mandate to execute the phased transition of the Jito Stake Pool to StakeNet control. At the end of the transition, the Stake Pool will be managed entirely on-chain, offering enhanced transparency, community involvement, and greater censorship resistance.

8. Cost Summary

This proposal will incur no immediate cost to the DAO. Future related proposals may request bug bounty funds for community audits of StakeNet as well as a fund for incentivizing keepers.

5 Likes
4

I have three concerns for the stakenet setup, but generally the proposal looks good based on this and the readme in the steward program folder.

  1. Historical commission threshold could cause a problem for validators with configuration errors that are then fixed. I don’t think I have ever seen this for main commission but I remember seeing for MEV commission a user unintentionally setting their commission to 100% due to a configuration mistake on their hot spare server. Vote accounts also set their commission to 100% by default which might not be noticed by a new inexperienced validator. These types of mistakes are not difficult to make and could make a validator ineligible for a stake forever even though their validator is in good standing the majority of the time. I am not completely sure what to do about this problem though. One simple solution is possibly ignoring commission rugs if they only take place for a very low number of epochs but that also mostly bypasses the check in the first place.

  2. There is no historical mev commission threshold. Rug pulling mev commission is concerning and there doesn’t appear to be any check if someone has done it in the past. Although given instant unstake will unstake them within 1 epoch this might not be too big of a issue and then they could be added to the blacklist after the attempt to scam.

  3. Have there been audits for the steward and other stakenet programs? In this case it may not be as important as other programs given it doesn’t directly hold any funds, but if someone could possibly forcibly stake themselves large portions of the pool possibly with a very high commission that would be very bad. That scenario seems unlikely but I would still prefer a second check by a skilled team.

I could also generally make some arguments about the rebalance system, but that is likely a topic for another JIP. This just implements the status quo in a decentralized manner which is likely the best choice until there is a consensus on if there is a better system and what it is and then a DAO vote takes place.

I also did not check the source code of the program so that might also have problems I didn’t mention here.

5

I see this as a step in the right direction and support JIP 3

1 Like
6

Thanks for the thoughtful proposal.

I spoke to Buffalu briefly at Snapshot, and he mentioned that there are still ways to improve the workaround for the ban list on StakeNet. I think it would be good practice to provide the community with a detailed overview of the current ban list and how it will be implemented on StakeNet. From my understanding, things are more manual currently, and the automation of StakeNet needs to consider specific characteristics that might not be simple to translate.

Regarding the partial transition phase, could we get a more specific breakdown of the phases within the three to six months of transition? It’s not necessary as of now but the closer we get to that phase it would be nice to get more clarity the closer we get to that phase. While there are no immediate costs, the proposal does not clearly outline the long-term financial implications, especially related to bug bounties and incentivizing keepers. A low-level cost-benefit analysis would provide more transparency.

The complexity of the state machine governing the transition phases might introduce operational challenges. If the state machine is not robustly designed and tested, it could result in unpredictable behavior. Who is auditing the code, and should we consider another professional audit before launching bug bounties, or is that overkill?

Who will be part of the oversight committee regarding Jito Labs’ control? Lastly, it would be beneficial to push some educational content regarding the scoring parameters for validators on StakeNet.

1 Like
7

Following the Twitter spaces just now I just want to add a point re upgradeability, I think it would be desirable for upgrade authority to be transferred to the DAO prior to pool authority being transferred to stakenet

2 Likes
8

Appreciate the support!

9

Regarding the permanent solution to the ban list, I’d recommend consulting the latest JIP. The DAO will have the opportunity to vote on how to implement a list provided by a Solana community-wide committee, which is currently being formed, at a later date.

With regard to the transition phases, I’d note that they’re broad by design. This is to give Jito Labs ample time to ensure that key components of StakeNet are functioning properly before handover. That said, Evan from Jito Labs added a few bars that Labs will be monitoring StakeNet to clear in order to transfer control. These have been added to the proposal, particularly to Phase 2, and are briefly listed here as well:

  • Minimum 3 cycles (30 epochs) successfully completed on mainnet without any bug fixes required
  • Minimum 2 independent parties besides Jito Labs running Steward keepers with demonstrated reliability of landing transactions
  • Demonstrated ability to continue state transitions during network congestion
  • Bug bounty program live for 3 months without critical / high severity vulnerabilities reported

We’ve added a note that StakeNet has been audited by Ottersec. Unfortunately, there are edge cases that cannot be predicted, which is another key reason for the transition period.

There are currently no plans in place for an oversight committee for the StakeNet transition. We will be pushing additional StakeNet scoring data as it becomes available, as well as a more user-friendly explanation of the scoring and how stake delegation will work!

2 Likes
10

Curious about the rationale for this move? The DAO’s processes would mandate, at minimum, a 35-day period for any changes if an edge case did occur while upgrade authority was in control of the DAO. This could be potentially disastrous – one such example was a Compound exploit where it took the DAO a number of weeks to implement a fix.

For reference, upgrade authority will be maintained by Jito Labs and/or the Security Council for an extended period after pool authority is transferred to StakeNet. This would ensure the ability to respond in a timely manner to any emergencies, though it would create a point of centralization prior to an eventual handoff of upgrade authority to the DAO on a much longer term time horizon after StakeNet has ‘proven’ itself live onchain. We envision this last handoff as being the final step to full decentralization of the protocol, and will take the longest to implement.

1 Like
11

Hi @Hero, this reply comes courtesy of Evan from Jito Labs:

Thanks for the responses and thought put into the components of scoring. A few thoughts:

  1. Historical commission banning is less common than you might think. In the Stakenet Validator History data, of all active validators who have had a commission less than 100% since epoch 500, the number of validators who are currently ineligible due to this threshold is 22, out of 1371. Of the validators that would have otherwise been eligible for the pool, there are only 4, and all of those exhibit behavior of commission rugs. Lastly, data will only start getting tracked after 5 epochs in the Validator History program, so any configuration errors in the initial setup should be worked out by then. The score is attempting to filter for professional and honest operators, and if there are significant setup errors around commission it may be a sign they aren’t diligent on behalf of their stakers. However we still may want to have some way for validators to be “redeemed”, and have considered options like a commission changes to be forgiven after some number of epochs, say 100. Thoughts on this or other simple solutions here? Also curious to hear concerns on this from other validators. Data based on epoch 610 in this sheet: https://docs.google.com/spreadsheets/d/1iWdQTNoAlz2W5qnKnP0LGLeka9BRWXi8Oy4ZqJnD_0E

  2. While it’s true there is not as strict of checks around MEV commission as validator commission, this is intentional, and there are still ways to prevent malicious behavior.

First, the mev_commission_range is the window for which we will look at MEV commissions, to ensure there is no commission in that range above mev_commission_threshold. Second, if in any single epoch the mev_commission is raised above mev_commission_threshold, that validator will be marked for instant unstaking. Finally, MEV is still a much smaller part of total yield for stakers (<15% of yield), so the checks don’t need to be as stringent.

  1. See other responses on audit
12

We support the motivation to advance the protocol towards progressive decentralization and believe this is the correct path. However, the protocol should carefully consider the timeline and the involvement of the DAO in this matter. While we would like Jito Governance to have some involvement in the upgrade authority, as Andrew mentioned, this would delay each step in the process for at least 35 days, so scheduling the handoff later is reasonable.

Regarding the launch of StakeNet itself, we seek clarity on the parameters involved and any future parameters planned for inclusion in the protocol. From our understanding, StakeNet is made of two important components: the Validator History Program and the Steward Program. The Validator History Program senses and reads validator information, both onchain (MEV, epoch credits, commission, supermajority status) and offchain (IP, client type, and client version). The Steward Program assumes staking authority, with the ability to add/remove/delegate/undelegate. According to the example provided by Buffalo’s Substack and the StakeNet Deep-Dive, the most important parameters for scoring validators are:

  • Vote Credits

  • Commission

  • MEV Commission

  • Validator Version/Type

  • Total Stake

  • Skip Rate (block production failures)

  • Superminority Status

Where we seek the most clarity is in the weighting system. While we understand that it is in development, we believe it would be beneficial to share this with the community, along with any parameters considered for the future and future plans for additional parameters.

13

Hey Jito community, Jito Labs is planning to transfer the Staker authority of JitoSOL to the Steward Program on Monday afternoon, around 2pm EST, barring any significant issues arising before then. Here are some updates about the progress of StakeNet development in preparation for the transition.

1 Like