Fjord Token Staking

Summary:

The FjordStaking contract allows rewards to be added even when there are no active stakes. This can lead to reward tokens being locked in the contract, as they cannot be distributed until users start staking again. This results in inefficiencies and potential delays in reward distribution.

Vulnerability Details:

The addReward function permits the addition of rewards without checking if totalStaked is greater than zero.
During the _checkEpochRollover, if totalStaked is zero, the calculation for pendingRewardsPerToken results in no rewards being distributed because it involves dividing by totalStaked.
As a result, any rewards added during such periods remain locked in the contract until staking resumes.

#Scenario:

• The rewardAdmin calls addReward to add tokens as rewards to the contract.

• At the time of adding rewards, totalStaked is zero because no users have staked tokens.

• The _checkEpochRollover function is triggered, but no rewards are distributed due to the zero totalStaked.

• The added rewards remain in the contract, locked and unused, until users start staking again.

Impact:

Inefficient Use of Resources: Rewards are not utilized effectively, as they remain locked in the contract.
Delayed Reward Distribution: Users who stake later may experience delays in receiving rewards, as previously added rewards are not distributed until new stakes occur.

Tools Used:

Manual review

Recommendations:

Check Before Adding Rewards: Implement a check in the addReward function to ensure that rewards are only added when totalStaked is greater than zero. This prevents rewards from being locked when there are no active stakes.
Queue Rewards: Consider implementing a mechanism to queue rewards for future distribution once staking resumes. This could involve maintaining a separate ledger for rewards that are added when totalStaked is zero.