3

I was wondering how inflation rewards are added to a stake account. I can't find any transactions that transfer the rewards to a stake account. There is a special block where the inflation rewards are accounted for (usually the first block of the next epoch) but this block has 0 transactions.

I'm asking because I noticed some weird behaviour in epoch 683. I was querying the inflation rewards for a stake account at this epoch on three different dates. First it showed inflation rewards of 234966 lamports, then 234967 lamports and now again 234966 lamports. It differs only by one lamport, so I assume some rounding issues?

I'm using gagliardetto/solana-go to fetch the inflation rewards:

inflationReward, err := c.rpcClient.GetInflationReward(
    context.Background(),
    stakingAccount,
    &rpc.GetInflationRewardOpts{
        Epoch:      epoch,
        Commitment: rpc.CommitmentConfirmed,
    },
)

The code fetches the inflation rewards of all stake accounts of a specific staker. These stake accounts get merged at some point. Could it be that there are rounding issues on chain when stake accounts get merged? Like one stake account has 5 lamports as rewards and the other 7 lamports but when merged it has only 11 lamports?

1 Answer 1

4

You've got it all right: staking rewards are currently added during the first block of an epoch, without any transactions showing the new lamports going into the account.

Since it would break consensus if two nodes calculated a different amount for the staking rewards, you can be sure that a consistent amount was deposited into the account. So if you see a difference, there's likely a rounding error in some client code somewhere. We would need some more information to check that though.

Note: this will change with Partitioned Epoch Rewards going out with v2, but the concept is still the same -- the lamports are minted into the account, but not at the first block.

2
  • Thanks Jon, I added some more information to my question. Commented Nov 4 at 11:06
  • Without any hard evidence of this issue, it's a bit tough to debug, but remember that it's impossible to have rounding errors at the chain level, since all validators need to have the exact same view of the network. There are issues encoding large numbers over JSON RPC, but these numbers fit very safely within those limits. It might be good to send an issue to the maintainer of the Go library if the code is open source
    – Jon C
    Commented Nov 4 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.