Why are there 3 stake pool deployments?
Understanding the 3 stake pool deployments on Solana.
There are 3 deployments of the Solana Program Library (SPL) Stake Pool Program:
Original SPL:
SPoo1Ku8WFXoNDMHPsrGSTSG1Y47rzgn41SLUNakuHySanctum SPL 1:
SP12tWFxD9oJsVWNavTTBZvMbA6gkAmxtVgxdqvyvhYSanctum SPL 2:
SPMBzsVUuoHA4Jm6KunbsotaahvVikZs1JyTW6iJvbn
All these deployments currently run the exact same program. However, each deployment is meant for a different purpose, given the wide variety and scope of different LSTs, and may diverge in the future.
1. Original SPL: Best for original stake pools
Stake pool liquid staking tokens (LSTs) are in the business of decentralising the network by distributing stake across dozens to hundreds of different validators. These LSTs have a target distribution of stake across validators and actively rebalance stake to ensure high yields and decentralisation. Choose this deploy if you wish to actively manage and rebalance stake from dozens or hundreds of different validators.
Examples of LSTs under this deployment: jitoSOL, bSOL, aeroSOL, vSOL
2. Sanctum SPL 1: Best for large protocols, single validators
Note: The Sanctum SPL 1 deploy is the best fit for the vast majority of projects’ needs and hence we recommend it.
These are for large protocols with their own in-house validators or for single validator LSTs. This deploy is meant to be upgraded to an improved version of the Solana SVSP program, which will minimise maintenance/rebalance burden and remove the need to run update cranks. Choose this deploy if you have one or few (<10) validators and are not interested in actively managing/decentralising stake.
Examples of LSTs under this deployment: hSOL, dSOL, compassSOL, 30+ other LSTs
3. Sanctum SPL 2: Best for maximal APY (personal/ product LSTs)
Sanctum LST 2 is meant to be upgraded to a version of the Infinity program, which will allow the LST to hold other LSTs. This could significantly increase the APY. However, the Infinity program is not as battle-tested as the SPL contract, and is therefore slightly more risky. Choose this program if you are comfortable with some additional risk in the future when maximising APY.
Examples of LSTs under this deployment: jupSOL, pineSOL, fpSOL, uwuSOL, flojoSOL…
Why have multiple deployments?
Separating different LSTs to different deploys gives us the flexibility to upgrade the SPL stake pool program in ways that are good for each type of LST, without harming the interests of the others.
All three deployments have a large and diverse multisig. The upgrade authority is not frozen because program upgrades will, for the foreseeable future, be needed. For example, the upcoming Partitioned Epoch Rewards upgrade of the Solana validator client may require an upgrade to all these programs. The community is also considering to cap the maximum withdraw fee any LST can set – this will also require a program upgrade.
All necessary upgrades will be propagated to all three deployments which will remain identical until a future date where they may diverge – although we expect this divergence process (if any) to be very slow and conservative, with consensus from all stakeholders.
Last updated
