SIMD-0677 would record five epochs of validator commission on chain
Serguey Asael Shinder2 min readA new Solana Improvement Document, SIMD-0677, proposes adding a short commission history to every validator's vote account. The draft, opened on 30 September by Umar Bhatty and marked with the status "Idea", is a core change that extends the Vote Account V4 format from SIMD-0185.
The problem it addresses. SIMD-0249, which activated on mainnet-beta at epoch 991, delays every commission change by a full epoch: inflation rewards for an epoch are calculated using the commission from the vote account as it stood at the start of the epoch before. SIMD-0123 applies the same rule to block-revenue commission. That stopped validators from raising commission at the last moment before rewards were paid, but, the draft argues, it changed what the vote account tells you. The two commission fields now show the rates that will apply two epoch boundaries ahead if nothing changes, not the rates being charged. The effective rates exist only in each validator's in-memory epoch-stakes snapshots and cannot be read from any account, sysvar or syscall.
According to the proposal, that has three consequences. An on-chain program cannot learn a validator's effective commission, although stake pools and liquid-staking scorers choose validators partly on it. Off-chain, the true rate can only be reconstructed by someone who captured the account at each of the last two boundaries. And a validator can still exploit the delay by raising commission, holding it for an epoch and lowering it again — each single snapshot looks fine, and nothing on chain keeps the sequence. The author says the delegation scorer they operate maintains its own ten-entry history through a crank that must run every epoch.
The design. A commission_history field would be appended to VoteStateV4. At each epoch boundary the runtime writes one entry — the epoch number plus the inflation-rewards and block-revenue commission in basis points that apply to it — and keeps the latest five. Each entry takes 12 bytes, so the field needs at most 68 bytes, and the vote account's fixed size of 3,762 bytes stays the same because V4 freed space when it removed older fields. Only the runtime writes the field, so validators cannot forge it.
The author describes it as an interim measure. SIMD-0511, a separate proposal, would expose the stake-weighted epoch data more fully, but not before the Alpenglow consensus change and only for the admitted validator set.
What it means
The proposal is at the earliest stage and may change or stall. Its value is in naming a gap that the commission delay created: the number delegators most need is the one the chain does not show. If it is adopted, stake pools could drop their own tracking cranks and read one account.