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 rate behind a reward can come from an earlier epoch

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.

The request remained open on Oct. 30, with no linked implementation. Its example of a low displayed rate alongside a high saved rate illustrates a possible pattern; it does not identify an observed validator incident or establish overcharging.

Linking a historical payout to its commission therefore requires more than the receipt: the reward period, the stake account's delegation to a validator, and the rate selected by the applicable historical rule. These records have to describe the same payout. A historical commission observation from the wrong boundary is still the wrong rate.

Historical tools can help connect the payout and the rate

Jito's Validator History Program documents up to 512 epochs of history per validator, including commission. Its copy instruction reads commission from a vote account and records the epoch and slot. That can preserve historical observations, but the instruction alone does not establish that an observation equals the delayed effective rate used for a particular payout.

Staking protocol Marinade's snapshot parser documents a more direct route to the cached state used for commission selection. It extracts the inflation commission from epoch-stakes snapshots and publishes the vintage of the value, along with fallback counters.

Those details matter as much as the rate itself. Marinade warns about archive boundaries and older output files without vintage metadata. A stored number without its capture context cannot safely be assumed to represent the effective rate. The documented parser provides a reconstruction method, rather than a guarantee that a complete archive is available for every account and epoch.

Data provider Trillium takes a different approach to measuring what delegators earned. Its APY methodology describes measuring inflation return from stake-account growth from epoch 1070 onward, using eligibility checks and RPC fallbacks without relying on displayed commission. Earlier epochs use different methods.

That distinction is useful: measuring net earnings can remain possible even when the applied commission is absent from a reward record. But measuring the return does not independently verify the fee that produced it. Trillium also distinguishes an unknown result from zero when suitable account evidence is missing.

For a SOL holder or staking product, a useful income record would connect the net reward to its period, validator delegation and effective commission evidence. Where reconstruction or sampling is involved, that record also needs to make its coverage limits clear.

There are proposals to make the connection easier. An October vote-state discussion considers storing commission rates alongside the epochs when they take effect. The open RPC request seeks a view of the effective rate already used by the runtime. Both remain proposed remedies in those records; neither establishes a deployed fix.

The scope also matters. Inflation commission, MEV commission and block-revenue sharing are separate components. Restoring visibility into one rate would not, on its own, explain every part of a staking return.

CryptoSlate's September coverage of reward-linked vote credits made a related distinction: performance measurements could not be converted into an individual holder's SOL payout loss without account-level evidence. Commission reporting requires the same care about what a measurement actually proves.

A reward record that omits its applied commission leaves a holder with more work: connect the payout to the correct historical rate, using evidence whose timing and coverage can be checked. P2P.org says rewards reconcile. Explaining the fee behind those rewards requires that additional link.