Solana reward records no longer show the commission taken, and stakers cannot check the fee from the payout alone

Solana’s reward records no longer carry the validator commission rate applied to each payout, so a staker can see how much SOL arrived but cannot read from that record what fee was taken. The change comes from Agave pull request #12588, merged on 20 May 2026 and switched on by the SIMD-0232 upgrade. Staking provider P2P.org dates the effect to 8 September in a report published on 30 October, CryptoSlate covered it on 1 November, and our own reading of mainnet data matches that date.

This is a transparency gap, not an overcharge. No document we read names a validator or accuses one of taking too much. The reward calculation still uses the commission, and the amounts are written as before. The record has lost the rate and nothing else in it.

What the reward record still shows, and what it no longer shows

In the Agave code, the field commission_bps becomes optional in the runtime’s reward structures and is left empty once the feature custom_commission_collector is active. A comment in the code says it will always be empty after SIMD-0232 activates and can be deleted during later cleanup. The pull request says plainly that this reaches the outside world: the same field feeds the RPC getBlock response and Geyser’s blockSubscribe message.

The amounts, commission_lamports and stake_reward, are untouched. So the sum paid to a validator and the sum paid to a delegator stay on record. The percentage that links them does not, and the pull request shipped with no linked issue and no migration note. An empty field does not mean a validator charged nothing, a point CryptoSlate also makes.

If you are new to the mechanics, staking on Solana means delegating SOL to a validator, which keeps a percentage of the inflation rewards. The rate used to sit next to each payout, and third-party software could simply read it.

The field was removed on purpose

The removal was deliberate and reviewed in public. SIMD-0232 lets validators name separate collector accounts for block revenue and for inflation commission. Its author, Justin Starry of Anza, leaves the calculation of the inflation commission rate unchanged, and the text is silent on RPC and reporting fields.

The pull request’s author, buffalojoec, argued that a single reported rate stops meaning much in an accumulated reward once collectors can be mixed and matched. Reviewer AshwinSekar agreed that reporting it “doesn’t make much sense” in that setup.

Stake rewards were the one point of debate. Reviewer joncinque asked whether to keep the rate there, since “there won’t be any mixing and matching” on a stake reward until multi-stake arrives. The author preferred removing it everywhere, and joncinque approved anyway: “If we’re sure we don’t want to report these for stakes, looks good to me!” The author also noted during the review that the field “is not part of consensus”, so emptying it does not change what validators agree on.

Block-revenue sharing under SIMD-0123 is a separate job and not the cause. Its tracking issue, #13538, was still open on 1 November, and in the related pull request #13503 a reviewer noted that block_reward “is always zero here”.

P2P.org’s 8 September date holds up on chain

“From 8 September, Solana stopped recording the commission rate applied to each epoch’s rewards,” P2P.org wrote. The SIMD-0232 file reads “Activated” but gives no epoch or date, so we looked at the chain. The feature account for custom_commission_collector shows activation at slot 445,392,000, the first slot of epoch 1031, which carries a timestamp of 17:11 UTC on 8 September.

The reward data moves at the same point. On 1 November we queried a public Solana RPC server for getBlock and getInflationReward. Two blocks at the 7 September payout, for epoch 1029, listed commissionBps on their staking rewards, and so did the reward of the largest validator by stake (700, or 7%). Two blocks at the 8 September payout, for epoch 1030, had no such field on about 6,000 rewards, and the same validator’s entries for epochs 1030, 1031, 1032 and 1072 had none either. That is a sample, not a full audit, but it agrees with P2P.org on the date and on both voting and staking records being affected.

P2P.org also has something to sell. Its report, by André Caldeira, says the company rebuilt its data around transactions, claims a 99.9% match with its own snapshot data across millions of accounts, and closes by pointing readers to its reward reporting. It gives no method for that figure and we could not verify it. On the central point the report is calm: “Commission is charged as before and reward amounts still reconcile.”

P2P.org says the change came without an announcement, that third-party migration guides kept showing the old format, that it spotted the change on the first affected epoch, and that it raised it with the Solana Foundation and Anza. We found no public reply from either.

Solana validator commission: what stakers can and cannot check today

The two lists below are our own summary of the sources cited here.

You can check:

• The SOL each stake account received, from the amount and post-payout balance in the reward record.
• The commission a validator sets right now, through the getVoteAccounts RPC method.
• Past commission settings, by replaying a vote account’s transaction history or by using a tool that stores it.

You cannot check, from the payout record alone:

• The rate applied to a given reward. It now has to be rebuilt from history, which P2P.org says also means reconstructing the delegation at that time.
• How amounts break down when several vote accounts share a collector. P2P.org says those pooled sums cannot be split back.

CryptoSlate lists tools for the history route, with limits. Jito’s Validator History Program documents up to 512 epochs per validator, but a stored value alone does not prove it equals the delayed rate behind a given payout. Marinade’s snapshot parser publishes the vintage of each value, and it is a reconstruction method without a promise of complete archive coverage. Trillium’s APY method sidesteps the displayed rate and measures stake-account growth from epoch 1070. We did not test any of them.

P2P.org says records from before 8 September are intact, which fits the epoch 1029 entries we read. We found no report of an exchange, custodian or tax tool breaking.

A second gap: the live rate may not be the rate in force

A related problem sits in a different place, and the two should not be merged. Under SIMD-0249, which participants in the debate confirm is active on mainnet, rewards for epoch E are calculated at the start of E+1 using the commission recorded at the start of E-1. The delay gives delegators time to leave after a rate change. It also means the number on a dashboard may not be the number being applied.

Issue #16135, opened on 18 October by ax-x2, says getVoteAccounts can show a 0% setting while Agave uses a saved 100% rate for the current epoch. The issue sketches a pattern: raise commission to 100% near the end of one epoch, drop the live value to 0% after the snapshot, repeat. That is a hypothesis. We found no report of it happening, and CryptoSlate says the issue’s example identifies no observed incident and does not establish overcharging.

GitHub user ripatel-fd raised the wider concern in July, in discussion #583 of the SIMD repository: “Users do not have an RPC API to see the effective current commission and collectors of a vote account.”

Several fixes are on the table, none deployed

Issue #16135 proposes an opt-in includeCommissionContext option on getVoteAccounts, returning the effective rate with its epoch and slot. On 1 November it had no assignee, no comments and no linked pull request.

In discussion #583, SIMD-0511 would store per-epoch commission and collector state on-chain, and another participant floated an interim vote-account field. In July, Justin Starry and joncinque favoured shipping both SIMDs as written and following up later. The last comment, dated 5 October, has joncinque proposing a new SIMD to use live collector addresses, which would not fully remove the caches.

For holders of Solana liquid staking tokens, or anyone delegating directly, nothing in the sources suggests a change in what is paid. This is also a separate matter from the Solflare validator incident of late October.

P2P.org lists a supported source for historical applied rates, or a reporting standard, among its items to watch in the fourth quarter.