In the staking contract, a user's rewards may be inaccurately calculated as zero when claimed after 1 or 2 epochs of staking. This issue arises because the totalStaked value is not updated before calculating the rewards, resulting in the use of an incorrect total supply. Consequently, the rewards for the previous epoch are missed, and the user is penalized by receiving a lower amount of rewards than they are entitled to.
The `_redeem` function in the staking contract is responsible for accumulating unclaimed rewards for a user and updating their staking data. However, there is a logical flaw in the order of operations within this function, which leads to incorrect reward calculations.
The current implementation of the `_redeem` function is as follows:
In this function, the rewards are calculated and added to `ud.unclaimedRewards` before the `totalStaked` value is updated:
Since `ud.totalStaked` is updated only after the rewards calculation, the function uses an outdated total supply value, leading to a reward calculation of zero for the user. The missed rewards from the previous epoch are effectively skipped, and the user loses out on the rewards they should have received.
This vulnerability results in users receiving inaccurate rewards, which can be significantly lower than what they are entitled to. The error occurs because the staking data is not correctly updated before the rewards are calculated, causing the contract to overlook the rewards for the previous epoch.
Manual Code Review
1. **Reorder Operations in `_redeem` Function**: The reward calculation should occur after the `totalStaked` value is updated. This change ensures that the correct total supply is used in the calculation. Specifically, move the following lines to the end of the `_redeem` function:
The corrected `_redeem` function would look like this:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.