Fjord Token Staking

Summary

Description: Users who stake using the stakeVested function can begin claiming rewards after the first week, even with a penalty, and continue claiming weekly. These users benefit because the RewardPerTokenChanged is updated after each claim, allowing them to accumulate rewards. In contrast, users who wait multiple weeks without claiming are disadvantaged, as claimReward only grants rewards for a single epoch, regardless of how long they waited. Additionally, there appears to be a discrepancy in the reward calculation, where the amount received differs from what is emitted in the EarlyRewardClaimed event.

Vulnerability Details

1. The user stakes their asset and then calls claimReward with the parameter set to true, allowing them to receive their reward after the first week with a penalty applied.

2. The user's balance increases as expected, reflecting the penalty. After another week, the user claims their reward again.

3. We then skip a total of 5 weeks, and the user claims once more. Despite expecting 5 weeks' worth of rewards, the user receives only a slightly larger amount, indicating they only received one epoch's worth due to the RewardPerTokenChanged being updated.

4. We call balanceOf and notice that the token balance is slightly different from the expected amount, indicating a discrepancy between the protocol's expected reward value and what the claimReward function actually provides.

Impact

This creates unfairness and potential misuse of the staking functions, resulting in some users being dissatisfied and leading to uneven distribution of rewards among participants. Additionally, it grants users early access to rewards, contrary to the expectation that rewards should be penalized between weeks 3 and 6 of staking.

Tools Used

Manual Review

Recommendations

For the math miscalculation, it seems to stem from the penalty division, leading to discrepancies. It might be beneficial to use OpenZeppelin SafeMath.sol or Math.sol contracts to ensure accurate calculations.

Users should not be allowed to withdraw their rewards until after 3 weeks, with penalties applied as described in the protocol. Implement a check to ensure that the initial unclaimedRewards in the userData is 3 or above, and add a boolean flag to indicate whether the user has claimed rewards within their first 3 weeks.

For the staking issue, consider attaching a number of epochs to each user. This way, when the checkEpochRollover modifier is called, you can retrieve the number of epochs the user is entitled to, ensuring correct reward distribution.

Add the updating of the epochAmount within the _checkEpochRollover function.

Add the slot.