How to check Solana staking rewards by epoch

Start from the position that earned the reward

Your ordinary wallet account, the validator's vote account and your stake account have different roles. For your native staking position's reward, begin with the stake account address.

A wallet can manage several stake accounts. A managed native product can also split and rebalance them. Keep the relevant account list and any split or merge history for the period you want to investigate.

Identify the cluster and completed epoch. Staking state and rewards are period-specific. The account you own now may have had a different delegation or effective amount in the epoch you are examining.

An explorer can provide a convenient reward-history view. For reproducible records, retain the account, epoch, data source and observation time alongside the displayed SOL amount.

Read the reward fields in their own units

The RPC method getInflationReward accepts a list of addresses and an epoch configuration. It returns a corresponding list of reward objects or null where reward data is unavailable for an input.

A returned object includes fields such as epoch, effectiveSlot, amount, postBalance and an optional commission. Read the method's current contract when building a parser. A vote-address reward and a stake-address reward answer different accounting questions.

For a teaching record, choose an amount of 15,000,000 lamports. Dividing by 1,000,000,000 gives 0.015 SOL. If the chosen post-balance is 100,015,000,000 lamports, that is 100.015 SOL. The post-balance is the account's resulting balance, not an additional reward to add to the amount.

These chosen fields illustrate interpretation. An actual record must come from the relevant account and epoch. Preserve null as missing or unavailable reward evidence rather than automatically turning it into zero income.

A balance increase can contain several causes

Suppose a teaching stake account begins at 100 SOL, receives a 1 SOL external addition and is credited 0.015 SOL of reward. Its ending balance can be 101.015 SOL under those simplified assumptions.

The total increase is 1.015 SOL, while the reward record explains only 0.015 SOL. Calling the full increase staking income would misclassify the added principal.

Splits, merges and withdrawals can also move balances between accounts. If two accounts merge, the receiving account's increase is not entirely a new reward. Reconcile the relevant instructions and source account.

Keep a small ledger with separate columns for external funding, withdrawal, account restructuring and reward credit. The account balance then becomes a consistency check for the records rather than the sole source of the income calculation.

Keep reward and balance movements distinct

Keep other reward mechanisms in separate records

Inflation-reward lookup describes a specific protocol credit. MEV distributions or a product's incentives can follow separate collection, allocation and claim paths.

Jito's native stake-account harvesting guide, for example, distinguishes claimable amounts for native positions from JitoSOL's incorporated reward accounting. A claim changes a wallet or destination balance and should be linked to the underlying distribution period where that information is available.

If a product reports a total return including a particular stream, do not add that same stream again from another screen. Record what is already included and whether amounts are accrued, claimable or actually received.

Converting a reward into another asset is another transaction. The credited quantity, conversion price and resulting holding are useful records, but they should not blur the original reward source.

Build a useful multi-epoch history

For each account and epoch, store the source response, credited amount, post-balance and relevant state context. Add observed commission information only under its actual field meaning and period.

To answer how much SOL was credited, sum confirmed reward amounts over the selected accounts and epochs without counting merged histories twice. To answer why income changed, compare effective stake, activation, participation and applicable product rules.

A recent position with funds still activating has a different participation history from one effective throughout a period. The history should explain that difference rather than treating the lower amount as a faulty calculation.

Use reward history to answer how much the accounts were credited. For an annualised provider estimate, retain its window, components and net/gross definitions. Turning a few account credits into a network-wide rate introduces assumptions that the credit records alone do not establish.

Continue with commission and MEV to interpret reward streams, or the staking lifecycle when an account has not yet reached the expected state.

Common questions