SIMD-0511 would put each epoch's stake map on chain, inside the bank hash
Serguey Asael Shinder2 min readSIMD-0511, "On-Chain Epoch Stakes", was refreshed in a new pull request on 29 September, bringing the proposal and its Agave implementation onto current upstream code and updating the schema for the Alpenglow consensus work that landed after the first draft. The status is Review.
The proposal writes one system-managed account per epoch, at an address derived from the epoch number, holding the mapping from each vote account to its delegated stake. Each entry also carries vote account v4 reward fields, the validator's compressed Alpenglow BLS key and its canonical rank. Entries are 224 bytes, which keeps an account under 438 KiB at Alpenglow's cap of 2,000 validators, and all epochs from activation onward stay available as account state.
The author gives several reasons. Today the stake distribution, the basic input to consensus, is available only through RPC calls such as getVoteAccounts or from snapshot fields, so on-chain programs cannot use it: stake-weighted governance, stake-aware delegation without oracles, or computing the leader schedule client-side are all impossible. Indexers must poll RPC instead of subscribing to an account. And the epoch stakes in a snapshot manifest are not covered by the bank hash, so a snapshot with corrupted or tampered stakes loads successfully and the problem surfaces only later in startup. Putting them in an account places them inside the hash validators vote on, so corruption is detected at load time.
The pull request describes SIMD-0558 as complementary, providing current and next leader lookup through a syscall, and names the remaining review question: permanent history versus a bounded retention window.
Why it matters
Stake is the most important number on a proof-of-stake chain, and Solana programs cannot read it. Making it account state would let programs and indexers use the same data validators vote on, and would move one more piece of consensus data out of the RPC layer the proposal says should eventually leave the validator.