SIMD-0022

TL;DR

A new "multi stake" account that allows for multiple movements of stake, useful for simpler stake movement through more activations, deactivations, or redelegation.

Summary

A new "multi stake" account that allows for multiple movements of stake, useful for simpler stake movement through more activations, deactivations, or redelegation.

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. 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. For more background, here's an earlier proposal meant for only for redelegation: https://github.com/solana-labs/solana/pull/24762

Key Changes

• "multi stake": a stake account with multiple Delegation instances
• "small stake": a stake whose delegation is less than current minimum stake delegation amount

Impact

Validators likely see a small increase in memory usage from additional `Delegation` entries in the stakes cache, and perhaps a tiny increase in rewards payout time, but nothing substantial. Dapp developers have to deal with a new stake account type. This may break programs that try to deserialize any stake account. The network benefits as a whole: * stake accounts are more flexible for adding or removing stake, without splits and merges * stakers can easily redelegate without missing out on rewards

Backwards Compatibility

*(Optional)* While existing programs that create and use their own stake accounts are not impacted, those that accept any stake account will crash on multi-stakes. There's no way around that, since the proposal entails a new stake account variant.

Security Considerations

It's risky to change the runtime, especially the stake program and rewards payout. Thankfully, since this all operates on the level of the `Delegation`, as long as we pass all the instances as needed, none of the most sensitive parts need to change.