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

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


  • 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.


  • 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.


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.

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

1 Like

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.

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

1 Like