Solana’s reward records leave stakers with a gap in validator fee data

Solana’s staking payouts can remain visible while the validator fee, or commission, behind them becomes harder to verify. Agave leaves the commission-rate field empty in reward metadata when custom collectors are active, making a fee check depend on historical validator state as well as the SOL received.

In an Oct. 30 report, staking provider P2P.org said the commission record disappeared from both voting and staking rewards from Sept. 8. It said commission continued to be charged and reward amounts still reconciled. The reporting problem concerns the evidence explaining a payout, rather than an identified shortfall in that payout.

P2P.org sells staking and reporting services, giving it a commercial interest in the issue.

The change was explicit in Agave pull request #12588, merged May 20. It makes the commission field empty after activation of the custom-collector feature, covering accumulated validator commission rewards and individual stake rewards. The PR describes outward-facing reward payloads used by block queries and subscriptions.

An empty field does not mean a validator charged no commission. It means that piece of metadata is unavailable. Agave’s current calculation code still passes the commission into reward calculation before suppressing it in the reward record.

Custom collectors serve a separate purpose. SIMD-0232, the protocol specification for the feature, lets validators direct commission income to designated collection accounts. It explicitly leaves inflation commission calculation unchanged while defining new collection rules.

The PR’s rationale is that an accumulated reward can combine income directed to a collector, making a single commission rate inappropriate for that aggregate. The implementation also suppresses the rate for individual stake rewards. That removes a convenient piece of evidence even where a holder is examining one stake account.

Historical commission matters because Solana delays the effect of rate updates across its reward periods, called epochs. Under the SIMD-0249 rule, the normal sequence for rewards earned in epoch E is: capture the rate at the start of E−1, earn rewards during E, then calculate those rewards at the start of E+1. New vote accounts have fallbacks to later state when the earlier account history does not exist.

That timing separates the rate visible in a validator’s latest account state from the rate relevant to a particular reward period. Using the newest setting to explain an older payout can select the wrong input.

This visibility concern predates October’s report. A July 16 engineering discussion described effective commission and collector values held in cached runtime state that users could not inspect through an ordinary account read. Developers said the commission-delay rule was already active on mainnet and discussed addressing the cached-state dependence separately.

Agave contributor ax-x2 raised the same practical distinction in an Oct. 18 RPC request. The issue says getVoteAccounts and parsed vote-account data show the latest setting while reward calculation can use a saved rate. It requests an optional response containing the effective inflation commission, its epoch and the bank slot.