Solana Reward Records Drop Validator Commission Field, Leaving Stakers a Verification Gap

Solana stakers can still see the SOL their stake earns, but the validator commission behind each payout has become harder to confirm. Agave, a Solana validator client, now leaves the commission-rate field blank in reward metadata when a feature known as custom collectors is active.

The gap does not point to any missing money. It concerns the evidence that explains how a payout was calculated, which matters to holders, staking products and anyone producing income records.

What changed in the reward data

Staking provider P2P.org said in a report dated 30 October that commission information stopped appearing in both voting and staking rewards from 8 September. According to the firm, validators kept charging commission and the reward amounts still reconciled. The problem it described is one of documentation rather than an identified shortfall.

P2P.org sells staking and reporting services, so it has a commercial interest in how the issue is framed and resolved.

The underlying change was deliberate. Agave pull request #12588, merged on 20 May, empties the commission field once the custom-collector feature is switched on. It applies both to accumulated validator commission rewards and to rewards paid to individual stake accounts, and it affects the outward-facing reward payloads returned by block queries and subscriptions.

A blank field should not be read as a zero fee. It simply means that the item of metadata is no longer supplied. According to CryptoSlate, Agave's current calculation code still feeds the commission into the reward calculation before removing it from the published record.

Why custom collectors triggered the change

Custom collectors are defined in SIMD-0232, a Solana protocol specification. The feature allows validators to send commission income to designated collection accounts. The specification sets out new rules for that collection while leaving the way inflation commission is calculated unchanged.

The pull request's reasoning is that an accumulated reward may bundle together income routed to a collector, so attaching a single commission rate to that combined figure would be misleading. That argument is narrower than the change itself, however. The implementation also hides the rate on individual stake rewards, removing a convenient reference point even for a holder examining a single stake account where aggregation is not an issue.

The result is that a fee check which once could lean on the reward record now depends on reconstructing the validator's state at the relevant point in time.

Why historical commission is hard to pin down

The difficulty lies in timing. Solana does not apply a commission change immediately; its effect is delayed across the network's reward periods, known as epochs. Under the rule set out in SIMD-0249, rewards earned in a given epoch normally use the rate captured at the start of the previous epoch. The rewards are earned during the epoch itself and then calculated at the start of the following one. Newly created vote accounts, which lack earlier history, fall back to later state.

This staggered approach means the rate displayed in a validator's most recent account state may not be the rate used for a particular payout. Looking up the current setting to explain an older reward can therefore produce the wrong answer, even when the lookup itself is accurate.

The concern predates the October report. In an engineering discussion on 16 July, developers noted that effective commission and collector values sat in cached runtime state that users could not inspect with an ordinary account read. They said the commission-delay rule was already live on mainnet and discussed dealing with the cached-state dependence as a separate matter.

An Agave contributor using the handle ax-x2 raised the same point in a request on 18 October. The issue observes that the getVoteAccounts call and parsed vote-account data show the latest commission setting, while reward calculation may draw on a saved rate. It asks for an optional response field providing the effective inflation commission, the epoch it relates to and the bank slot.

That request was still open on 30 October with no linked implementation. It includes an example of a low displayed rate sitting alongside a high saved rate. CryptoSlate stressed that this illustrates a possible pattern rather than describing an observed incident or demonstrating overcharging.

How the ecosystem is filling the gap

Tying a historical payout to its commission now requires several pieces of evidence that must all refer to the same payment: the reward period, the stake account's delegation to a specific validator, and the rate chosen under the applicable timing rule. A genuine historical observation taken at the wrong epoch boundary still yields the wrong rate.

Several tools in the Solana ecosystem address parts of this problem, each with limits:

• Jito's Validator History Program records up to 512 epochs of history per validator, including commission, and logs the epoch and slot when it copies the value from a vote account. That preserves observations, but the copy alone does not prove a recorded value matches the delayed effective rate used for a given payout.
• Marinade's snapshot parser extracts inflation commission from epoch-stakes snapshots, the cached state used to select commission, and publishes when each value was captured along with fallback counters. Marinade warns about archive boundaries and older output files lacking that metadata, and the method does not guarantee a complete archive for every account and epoch.
• Trillium measures what delegators actually earned by following how stake accounts grow, starting at epoch 1070, and relies on checks of eligibility plus backup RPC sources rather than displayed commission. Earlier epochs rely on other methods, and the firm treats missing evidence as unknown rather than zero.

The Trillium approach highlights a useful distinction. Net returns can still be measured even when the applied commission is absent from the reward record. But a return figure does not independently confirm the fee that produced it.

The Marinade caveat makes a broader point: a commission number without its capture context cannot safely be treated as the effective rate. Provenance is as important as the value.

Risks and limits of the current picture

For now, there is no evidence in the reported material that stakers have been short-changed. P2P.org itself said rewards reconciled. The issue is that the ability to audit that conclusion has weakened, and that auditing now depends on specialist data that not every holder or product has access to.

That has practical consequences. Staking services, custodians and accountants who produce income statements may need records linking each net reward to its epoch, the validator delegation and some evidence of the effective commission. Where figures are reconstructed or sampled, those records would also need to state their coverage limits clearly, so that gaps are not mistaken for certainty.

It is also worth weighing the source of the alarm. A reporting firm drawing attention to a reporting gap has an evident business interest, even if the technical details are documented in public code and developer discussions.

What to watch next

Two proposals could narrow the gap. An October discussion on vote state considers storing commission rates together with the epochs in which they take effect, which would make historical lookups more direct. The open RPC request would expose the effective rate that the runtime has already used.

Neither has been deployed, according to the records cited by CryptoSlate. Whether either is adopted, and how quickly, will determine how long stakers and staking products must rely on third-party reconstruction to verify what validators charged.

Until then, the payouts remain visible while the explanation behind them requires more work to establish.