Solana staking rewards can still be paid and reconciled even when the validator commission behind them is not shown in the reward metadata. The issue has emerged after changes to Agave, the software client used by Solana validators, particularly when validators use custom collector accounts.
According to CryptoSlate, the missing data does not by itself indicate that a validator failed to pay a holder correctly or charged an improper fee. Instead, it makes it more difficult to verify which commission rate was applied to a particular payout. That verification may require combining the reward period, the holder’s delegation and historical validator records.
What changed in Solana’s reward records
P2P.org, a staking and reporting provider, said in an Oct. 30 report that the commission field disappeared from both voting and staking rewards from Sept. 8. The company said commission continued to be collected and that reward amounts still reconciled. Because P2P.org sells services connected with staking and reporting, its commercial interest in the subject is relevant when assessing its account.
The behavior was introduced through Agave pull request #12588, merged on May 20. Once the custom-collector feature is active, outward-facing reward data can leave the commission-rate field empty. The affected information includes accumulated validator commission rewards and rewards associated with individual stake accounts.
An empty field should not be read as a zero-fee setting. Agave continues to pass a commission rate into the reward calculation before suppressing that rate in the reward record. Custom collectors allow validators to direct commission income to designated collection accounts. The related protocol specification, SIMD-0232, leaves inflation-commission calculations unchanged while defining how collection accounts operate.
The rationale for hiding the rate is that an accumulated reward may combine income sent to different collectors, making one commission rate unsuitable for the aggregate. However, the implementation also removes the rate from individual stake-reward records, where a holder may expect a more direct explanation of the payout.
Why the current validator setting may be misleading
A second complication is timing. Solana’s rewards are linked to epochs, its staking reward periods, and the rate displayed in a validator’s latest account state may not be the rate used for an older reward.
Under the SIMD-0249 rule described in the source material, the rate for rewards earned in epoch E is captured at the start of epoch E−1. The rewards are earned during epoch E and calculated at the start of E+1. New vote accounts can use later-state fallbacks when the earlier account history is unavailable.
That sequence means a validator’s present commission setting cannot automatically explain a historical payout. A user trying to audit a reward needs the relevant epoch and the historical rate selected by the protocol, rather than simply the newest value visible through a standard account read.
The visibility concern predates the October report. A July engineering discussion referred to effective commission and collector values held in cached runtime state that were not available through an ordinary account read. On Oct. 18, an Agave contributor opened an RPC request seeking an optional response that would show the effective inflation commission, the epoch associated with it and the bank slot. The request was still open on Oct. 30, with no linked implementation.
The proposed RPC response would address a practical gap between what users can see and what the runtime uses. It does not, however, establish that any particular validator overcharged. The example attached to the request, involving a low displayed rate and a higher saved rate, illustrates a possible data mismatch rather than a confirmed incident.
Tools that can help reconstruct the applied rate
Several existing tools document ways to preserve or recover historical information, although each has limits.
Jito’s Validator History Program records up to 512 epochs of history per validator, including commission. Its copy instruction reads the rate from a vote account and records the epoch and slot. That creates a historical observation, but the observation alone does not prove it was the delayed effective rate used for a specific payout.
Marinade’s snapshot parser takes a more direct approach by extracting inflation commission from epoch-stakes snapshots. It publishes the value’s vintage and fallback counters, which help identify the context in which the rate was captured. Marinade warns that archive boundaries and older files without vintage information can limit reconstruction. A number without its capture context cannot safely be treated as the rate applicable to a particular reward.
Trillium’s APY methodology measures inflation returns by tracking growth in stake accounts from epoch 1070 onward. It uses eligibility checks and RPC fallbacks without relying on the displayed commission for those periods, while applying different methods to earlier epochs. This shows that net earnings may remain measurable even when the fee field is absent, but measuring the return does not independently confirm the commission that produced it. Trillium also distinguishes an unknown result from a zero result when account evidence is incomplete.
Proposals under discussion include storing commission rates alongside the epochs when they become effective and exposing the runtime’s effective rate through RPC. Neither proposal is identified as a deployed fix in the source material. In addition, inflation commission, MEV commission and block-revenue sharing are separate components, so clearer visibility into one rate would not explain every element of a staking return.
Current SOL market picture
Moneyiar market data at 12:49 p.m. on Nov. 1, 2026, shows Solana’s SOL at $94.785248008. The token was down 1.13% over 24 hours and 6.02% over seven days.
The market figures describe SOL’s trading performance, not the accuracy or completeness of validator reward records. For a staking holder, the reporting issue is primarily an auditability problem: connecting the net payout to the correct epoch, validator delegation and historical effective commission.
