Summary

In the staking contract, there is an issue where the total staked tokens are not updated immediately when a user stakes. Instead, the update occurs only at the beginning of the next epoch. This delayed update causes an incorrect calculation of rewards, particularly when new rewards are added by the admin. The current implementation fails to include the stakes made just before the reward distribution, leading to an unfair distribution of rewards. This scenario can result in a situation where the reward pool is insufficient to cover all eligible stakers.

Vulnerability Details

The vulnerability arises from the way the `_checkEpochRollover` and `addReward` functions handle the update of `totalStaked`. Specifically, the contract delays updating the total staked tokens until the next epoch, which can lead to incorrect reward calculations when rewards are added before this update.

Relevant code excerpts:

ERROR

NOTE : TOTALSTAKED SHOULD ADD NEW STAKED

**Issue Description:**

When the admin adds new rewards through the `addReward` function, `_checkEpochRollover` is called to handle the epoch transition and reward distribution. However, since `totalStaked` is updated only after the pending rewards are calculated, any stakes made just before the reward update are not factored into the reward calculation.

For example:

- **Epoch 1**: User A stakes 1000 tokens.

- **Epoch 2**: Admin adds 1000 tokens as rewards, and `_checkEpochRollover` is triggered. However, `totalStaked` still reflects the value from the previous epoch, and the newly staked tokens by User A are not included in the reward calculation.

- **Epoch 3**: User B stakes another 1000 tokens, but by this time, the rewards have already been distributed based on the outdated total staked amount.

This sequence causes User A to receive fewer rewards than deserved, while User B may receive more than deserved in the next epoch. Over time, this can result in a scenario where the rewards pool is insufficient to cover all staked tokens, leading to financial imbalances.

Reference to other implementations - https://github.com/Synthetixio/synthetix/blob/cd66f93fa41fc9b7eb97e21eaf8b5f6b9eea5ecf/contracts/StakingRewards.sol#L83-L85

Impact

This vulnerability results in an unfair distribution of rewards, where users who stake just before a reward update may not receive their fair share of rewards. Additionally, this mismanagement could cause the rewards pool to become insufficient.

Tools Used

Manual Code Review

Recommendations

1. **Immediate Update of `totalStaked`**: Modify the `_checkEpochRollover` function to update `totalStaked` before calculating `pendingRewardsPerToken`. This ensures that all stakes made before the reward distribution are accurately included in the reward calculations.