Fjord Token Staking

Summary

An issue arises if the addRewards() function in the FjordStaking contract is called near the end of an epoch but does not get executed before the epoch ends. This situation could result in the epoch ending without any rewards being distributed, leaving users without the expected rewards for that period.

Although the function's NatSpec documentation indicates that addRewards() is intended to be called at the end of an epoch to trigger the epoch rollover, this reliance on precise timing creates a risk that rewards may not be added in time, potentially impacting the reward distribution process.

Vulnerability Details

If the Ethereum network experiences high congestion near the end of an epoch, transactions may take longer to confirm. In such cases, the addRewards() transaction might not be included in a block before the epoch ends, resulting in no rewards being distributed for that epoch.
Another scenario might be a malicious user engaging in block stuffing—filling blocks with their transactions to delay or prevent the inclusion of the addRewards() transaction. By doing so, the attacker can manipulate the timing to cause the epoch to end without rewards being added, potentially disrupting the reward distribution mechanism.

Impact

The primary impact of this vulnerability is the inability to distribute rewards, which disrupts the core functionality of the protocol. Since reward distribution is fundamental to incentivizing user participation and maintaining trust in the protocol, any failure to distribute rewards undermines the protocol's reliability and user confidence. Given the essential nature of this functionality, the impact is considered high. The likelihood of this issue occurring is low/medium as this does not have direct incentives for the attacker

Tools Used

Manual review.

Recommendations

To mitigate this issue, avoid calling addRewards() near the end of an epoch. Another design would be to implement predefined minimum rewards for each epoch that are transferred in advance, reducing reliance on the timing of addRewards(). This approach ensures that each epoch has guaranteed rewards, regardless of when additional rewards are added.