Solana's reward records leave stakers with a fee data gap

Agave, a Solana validator client, writes reward records that leave the applied-rate field blank. That single empty field is the whole story. A staker looking at a reward entry has no way to confirm what fee the validator actually charged. The applied rate is the number that says what share of rewards a validator kept as commission. When it is present, a staker can check the math: rewards in, validator take out, remainder to the delegation. When it is absent, the entry only shows the result. The split that produced it is not recorded. This is not a rounding error or a display bug. The field is empty in Agave's records, so every reward entry it produces carries the same gap. The fee was charged and applied. The record simply does not say so. Verifying the fee now takes work. A staker needs historical validator state, meaning the validator's configuration at the time the reward was issued, plus delegation evidence, meaning proof of how much stake was active and when. With those two pieces, the fee can be reconstructed after the fact. Without them, the reward entry stands alone and unverifiable. That shifts the burden. Instead of reading a number off a record, a staker has to gather outside evidence and replay the calculation. For a single delegation that is tedious. For an operator tracking many validators, it is a real cost in time and tooling. The fee itself is not in question here. The gap sits in the audit trail, which is the thing a staker needs when a reward looks wrong. A missing field is exactly where an error would hide. What changes next depends on Agave. If the client starts writing the applied rate into reward records, the gap closes and verification returns to a glance. Until then, stakers who want certainty have to keep their own historical state and delegation evidence on hand.