The All-New Stake Account Version - Unlocking Enhanced Features on Solana
Shivam Soni
Introduction
In this article, you will gain an understanding of the new stake account version through the Solana improvement document(SIMD) for multi-stake accounts.
Who this article is for
This walkthrough assumes that you are aware of the Solana blockchain and its ecosystem.
Let's get started...
Table of Contents:
What is SIMD?
Terms that we use frequently in this article
Staking
3.1 what is staking
3.2 how does it work in Solana
SIMD for multi-stake account
4.1 Motivation
4.2 Stake account v2
4.3 Interoperability with Stake Account V1
4.4 New Stake Program Instructions
4.5 UpgradeToV2
4.6 Redelegate
4.7 New Vote Account Field
4.8 Runtime changes
4.9 Downstream effects
4.9.1 Stake Pools
4.9.2 Bots
4.9.3 Minimum delegation
What features multi stake bring
5.1 Adding or Removing Small Stake
5.2 Redelegation
5.3 Upgrade
Several implications of multi-stake for different stakeholders within the Solana ecosystem
6.1 Improved User Experience
6.2 Efficiency and Flexibility
6.3 Ecosystem Growth
6.4 Validators
6.5 DApp Developers
6.6 Network Benefits
How you can submit a proposal for SIMD
Conclusion
Further resources
What is SIMD
SIMD stands for Solana Improvement Documents (SIMDs) that describe proposals and changes to the Solana protocol.
How this brings a change in Solana we will discuss in the further sections
Terms that we use frequently in this article
Vote and Stake accounts
The Vote program solves the problem of making stakes slashable. The Stake program acts as custodian of the rewards pool and provides for passive delegation. The Stake program is responsible for paying rewards to the staker and voter when shown that a staker's delegate has participated in validating the ledger.
Delegation
Delegating means assigning your "voting rights" of your SOL to a validator. It's super simple. All staked SOL is delegated, so essentially staked and delegated mean the same thing.
Epoch
A period in time in computing, and in Solana, is about 2.5 days.
Validators
Validators form the backbone of Solana’s network. By processing transactions and participating in consensus, each validator helps make Solana the most high-performance blockchain network in the world.
Rent-exempt
An account is considered rent-exempt if it holds at least 2 years’ worth of rent. This is checked every time an account's balance is reduced, and transactions that would reduce the balance to below the minimum amount will fail.
Warmup and cooldown periods
Stakes, once delegated, do not become effective immediately. They must first pass through a warmup period. During this period some portion of the stake is considered "effective," while the rest is considered "activating." Changes occur on epoch boundaries.
The amount of stake that can be warmed up each epoch is a function of the previous epoch's total effective stake, total activating stake, and the stake program's configured warmup rate.
Cooldown works the same way. Once a stake is deactivated, part of it is considered "effective", and part "deactivating". As the stake cools down, it continues to earn rewards, and then, it becomes available for withdrawal.
Rewards are paid against the "effective" portion of the stake for that epoch.
Staking
What is staking
Staking is the process by which an SOL token holder (such as someone who purchased SOL tokens on an exchange) assigns some or all of their tokens to a particular validator or validator’s, which helps increase those validators’ voting weight. Assigning your tokens to add to a validator’s stake weight is known as “delegating” your tokens. Delegating your tokens to a validator does NOT give the validator ownership or control over your tokens. At all times, you still control all your staked tokens that you may have chosen to delegate.
How it works in Solana
When you create a stake account, you fund it with a specified amount of SOL tokens from your main wallet account. Tokens can also be transferred into an existing stake account using the wallet's transfer feature. However, if the stake account is already delegated, the newly transferred tokens will not be automatically delegated.
If you want to increase your delegation to a specific validator, it is best practice to create a new stake account with the additional stake amount and delegate that account to the same validator.
For example:
You have a wallet with a balance of 1000 SOL.
You create a stake account with 100 SOL and delegate it to Validator A.
Your wallet balance becomes 900 SOL, and you control a stake account with 100 SOL.
The stake account shows in the wallet interface and on the Explorer that it is “Activating”. Once it is “Active”, the staked tokens are eligible for rewards. See Timing Considerations for more details.
Later, you want to increase your delegation to Validator A. You create a second stake account with 50 SOL and delegate it to Validator A.
Your wallet balance becomes 850 SOL, and you control two stake accounts with 100 SOL and 50 SOL, both delegated to Validator A.
If you transfer tokens into a stake account that is already delegated, those tokens will not be automatically delegated. To have the new tokens delegated and earn rewards, you would need to un-delegate the entire account and then re-delegate it. However, this process takes time, and during the transition period, your original stake won't earn rewards.
SIMD for multi-stake account
In the proposed SIMD, the Solana community suggests the implementation of multi-stake, a new feature that enhances stake accounts on the Solana network. This proposal aims to address the challenges and limitations faced by ordinary users and developers when performing stake operations. By introducing multi-stake, Solana seeks to provide greater flexibility, efficiency, and ease of use within the network.
Motivation
Stake operations are cumbersome or impossible for many ordinary uses. For example, delegating more lamports in an existing stake account requires creating a new account, delegating, waiting, merging, then withdrawing the rent-exempt lamports(Accounts that maintain a minimum LAMPORT balance greater than 2 years’ worth of rent payments are considered "rent exempt" and will not incur a rent collection.).
The current stake redelegate instruction requires using a new stake account and eventually cleaning up the old one, which can be tricky to use.
As a minimum stake delegation amount is applied to the network, and potentially increased over time, these operations will become more complicated, since all delegations must clear that threshold. Small SOL amounts will be left liquid rather than delegated to a validator.
Additionally, stake pools always carry some risk or capital inefficiency for the stake pool operator. Either there's a requirement to leave liquid SOL available for small stakers to exit, or small stakes cannot enter because there's not enough to cover the minimum delegation amount.
Small stakes need to be delegated, while not causing problems in the validator's stakes cache.
Stake account v2
The current stake program is battle-tested, but time has revealed a few important issues:
- Redelegations are not possible
Whales can't easily redelegate their positions, since they do not want to lose out on an epoch of rewards.
- Rewards calculations at epoch boundaries take too long
Since all of the stake accounts simultaneously receive rewards at the start of an epoch.
The current StakeState is 200 bytes, and can be in 4 states:
UninitializedInitialized(Meta): the rent-exempt reserve, authorized keys, and lockupStake(Meta, Stake):Delegation(validator, stake amount, activation/deactivation epochs, warmup rate) +credits_observed(used for rewards calc)RewardsPool: deprecated
To properly perform a redelegation, we need to store at least the next validator's vote pubkey and a redelegation epoch, which means that redelegation absolutely requires a larger struct.
This proposal introduced a new type and an upgrade path from legacy / V1 stakes:
struct StakeV2 {
meta: Meta,
stake: Stake,
last_claim_epoch: Epoch, // needed to know if it's up-to-date, see ClaimRewards
redelegation: Redelegation,
}
struct Redelegation {voter_pubkey: Pubkey,
redelegation_epoch: Epoch,
credits_observed: u64,
}
With this information, we can calculate multi-epoch redelegations when the cluster sees more than 25% stake movement.
Interoperability with Stake account V1
Since loads of places use mem::size_of::<StakeState>(), and we still need to support that, that struct won't get touched. On the flip side, programs need to process both. Since there's already a neat interface on StakeState, we can do something similar with a new type:
enum StakeStateV2 {
Uninitialized,
Initialized(Meta),
StakeV1(Meta, Stake),
RewardsPool,
StakeV2(StakeV2),
}
impl StakeStateV2 {
/// ... all the same as StakeState ...
pub fn redelegation(&self) -> Option<Redelegation> {
match self {
Self::StakeV2(stake) => Some(stake.redelegation),
_ => None,
}
}
}
Programs update to use StakeStateV2 everywhere, and the existing code still works. When an Initialized stake is delegated, the stake program makes it a StakeV1 if the size is 200, and a StakeV2 if the size is 256.
New Stake Program Instructions
Split / Merge / Deactivate are only allowed if the stake account has been updated this epoch, or after deactivation epoch if applicable.
Deactivating might actually be OK since we could technically calculate the rewards even after deactivation.
UpgradeToV2
Given a V1 stake account, a signature from the stake or withdraw authority, and a funding account, reallocate the existing stake account and convert it to a V2 stake. The funding account adds the lamports necessary to cover the new rent-exemption.
This would also be a great time to include the rent-exemption in the delegation. That way, smaller stakers get a tiny bit more, and there are a couple of other nice side effects.
Redelegate
Given a V2 stake account, vote account, and stake authority signature, change the redelegation. Follows most of the same rules as a delegate.
If it's going through a multi-epoch redelegation, be sure that the previous epoch rewards have been claimed, and update the vote pubkey/credits/epoch.
(Also in the Vote Program) ClaimRewards
Given only a V2 stake account and the delegated vote account (or two vote accounts during multi-epoch redelegation), calculate the rewards gained since the last claim, and withdraw the lamports from the vote account.
This instruction is permissionless.
For easier use with existing tools, if a redelegation is complete, move the redelegation information over into the main delegation.
Implementation note: claiming lamports from the vote account and also updating the stake account is tricky since only the owning program can deduct lamports or modify data, and we need to do both conditionally.
Potential solution: the vote program CPIs into the stake program to update the credits observed, then transfers the lamports from the vote account to the stake account. The stake program must enforce that only the vote program can call it, otherwise, it's possible to deprive an account of their rewards.
BIG ISSUE TO CONSIDER: vote accounts only store 64 epochs of credits, which means that we can only accurately calculate 64 epochs of credits.
Potential solution: if it's been too long, drop rewards. This is easiest, but not great.
We can include a mechanism where it's possible to claim a tiny portion of rewards from an account if the update is done during the 64th epoch since the last claim.
This slice of the rewards could be claimable by anyone, or only the authorized voter on the account.
New Vote Account Field
Vote accounts need to keep track of withheld_rewards. We should be able to steal some bytes from prior_voters them since we only need a u64 for the withheld amount.
Withdraw needs to respect the withheld amount and rent-exemption. This means that vote accounts cannot be deleted if any withheld rewards remain. Thankfully, since claiming rewards is permissionless, a node operator can do this themselves
and then delete their vote account.
Validators may get confused about the lamports in their account, so improve the explorer/tools to show how much can be withdrawn, ietotal_lamports - rent_exemption - withheld_rewards.
While we're making changes to the struct, we can also widen the commission to a u16 and finally, let validators charge 6.9%, see https://degendaoo.academy/dics for more context.
Runtime changes
V2 stakes are not included in the stakes cache, but their delegation amounts are added to the vote accounts. Every call to the stake program will still hit the cache, but there won't be an entry to process at the epoch boundary.
Since the withheld rewards are included in the vote account, it will always have a totally accurate delegation amount, regardless of how much is claimed.
Also, since inflation still creates all new lamports at the epoch boundary, the runtime rules on lamport creation are never broken.
Downstream effects
Stake Pools
Stake pools and bots can keep using V1 stake accounts with no problem in this model.
Since V2 stakes have redelegation, all pools have a huge incentive to upgrade. Currently, during rebalancing, the moved amount loses one epoch of rewards, which is a problem for stake pool performance.
Also, since stake pools typically comprise many smaller stakers, and perform withdrawals through splitting stake accounts, they can keep servicing smaller holders while maximizing the staked amount in the pool.
Bots
Instead of staking to and from an inactive reserve stake account, bots can rebalance by doing a split, redelegating, waiting until activation, and then merging.
Funds that need high performance can update bots to do this fairly easily.
Minimum delegation
Since V2 stakes are not included in the stakes cache and are not computed at epoch boundaries, smaller holders can use them, or stake pools.
At the same time, V1 stakes can impose a minimum limit as high as needed.
What features multi stake bring
The proposal suggests the introduction of a new stake account variant called "multi-stake." This account allows for multiple delegations, referred to as "stakes," within a single account. Each stake operates independently and can have different delegation amounts, voting preferences, and validator associations. The multi-stake account simplifies stake operations by eliminating the need for account creation, merging, and withdrawal processes.
Adding or Removing Small Stake
Users can add small amounts of stake to their account by transferring the lamports and calling the delegate instruction. This creates a new stake delegation alongside the existing one. Once the new delegation is active, an update instruction consolidates the two delegations into one. Similarly, users can remove a small stake by deactivating a portion of it, adding a new delegation for the deactivating stake, and using the update instruction to clear the previous delegation.
Redelegation
With multi-stake, users can easily redelegate their stake from one validator to another within the same account. The process is similar to the existing redelegation instruction but keeps all the lamports within the account. A new delegation covers the redelegated stake, and the update instruction removes the previous delegation once it becomes inactive.
Upgrade
The proposal introduces an upgrade instruction that allows users to convert their existing stake account to a multi-stake account. This instruction reallocates the account to accommodate multiple delegations and updates the rent-exempt reserve field in the account metadata. The upgrade instruction must be signed by the current staker or withdrawer and can optionally include a payer to fund the additional rent-exempt reserve requirement.
Several implications of multi-stake for different stakeholders within the Solana ecosystem
Improved User Experience
Multi-stake simplifies stake operations and provides a more user-friendly experience. Developers can design applications that make it easier for users to delegate, redelegate, and manage their stake, thereby increasing user adoption and engagement.
Efficiency and Flexibility
Multi-stake enables more efficient and flexible stake management. Developers can build tools that allow users to adjust their stake allocations easily, optimize rewards, and respond to changing market conditions or validator performance.
Ecosystem Growth
The introduction of multi-stake enhances the Solana ecosystem by streamlining stake management and encouraging active stake participation. Developers can contribute to the growth of the ecosystem by building applications and services that leverage multi-stake to attract and retain users.
Validators
Validators may experience a slight increase in memory usage due to additional delegation entries in the stakes cache. However, the impact on rewards payout time and overall performance is negligible.
DApp Developers
Dapp developers need to adapt their programs to support multi-stake accounts and incorporate the new instructions introduced by this proposal. They should consider the changes in data structures, account state management, and user interfaces to ensure compatibility and take full advantage of the benefits offered by multi-stake.
Network Benefits
As a whole, the Solana network benefits from multi-stake by offering more flexibility in adding and removing stake without the need for complex splitting and merging processes. Stakers can easily redelegate their stake without missing out on rewards, enhancing participation and engagement.
How you can submit a proposal for SIMD
Tutorial
Gather feedback on your SIMD idea either here or in the Solana Tech Discord under the core-technology channel(here).
Once you get enough discussion on the SIMD where you think it may have a good chance of getting accepted, write your SIMD using the SIMD template
Create a PR to solana-foundation/solana-improvement-documents 7
SIMD maintainers will assign a SIMD number to your SIMD
Conclusion
In this article, we explored the new stake account version called "multi-stake" on the Solana network and its enhanced features. The proposal suggests introducing multi-stake as a solution to the limitations and challenges faced by users and developers when performing stake operations. By implementing multi-stake, Solana aims to provide greater flexibility, efficiency, and ease of use within the network.
The multi-stake account allows for multiple delegations, or "stakes," within a single account. Each stake operates independently and can have different delegation amounts, voting preferences, and validator associations. This eliminates the need for creating multiple accounts, merging, or withdrawing stakes.
The article discusses the key features and improvements that multi-stake brings to the Solana ecosystem. Users can easily add or remove small stakes by transferring lamports and calling the delegate instruction. Redelegation becomes a simple process, enabling users to switch their stake from one validator to another within the same account.
The proposed changes also include upgrades to the stake program instructions, such as UpgradeToV2, Redelegate, and ClaimRewards. Epoch boundary calculations are improved, and new stake program instructions are introduced to handle multi-stake accounts effectively.
The introduction of multi-stake has several implications for different stakeholders within the Solana ecosystem. It enhances the user experience, provides efficiency and flexibility, contributes to ecosystem growth, benefits validators, and facilitates DApp development. Stake pools and stake bots can also take advantage of the new features, improving their performance and ability to service smaller holders.
Overall, the multi-stake account version brings significant enhancements to stake operations on the Solana network, making it more user-friendly and efficient. With the proposed improvements, Solana aims to further strengthen its position as a high-performance blockchain network.
Further resources
Subscribe to my newsletter
Read articles from Shivam Soni directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by