Fjord Token Staking

Summary

The FjordPoints and FjordStaking contracts are designed to reward users with points tokens based on their staked amounts over epoch intervals. However, due to a timing discrepancy introduced during the deployment sequence, it is possible for an attacker to exploit this arrangement to claim points without having their tokens locked for a full epoch. Specifically, the FjordPoints contract initializes its epoch from the block timestamp at deployment, and the FjordStaking contract does similarly but is deployed subsequently in a different block. This time difference allows attackers to manipulate the system by strategically staking and unstaking tokens around epoch changes, thus violating the intended incentives.

Vulnerability Details

The issue arises from the interaction between the FjordPoints and FjordStaking contracts. Primarily, the constructors and epoch management logic in the following functions:

• FjordPoints Constructor:

https://github.com/Cyfrin/2024-08-fjord/blob/0312fa9dca29fa7ed9fc432fdcd05545b736575d/src/FjordPoints.sol#L118C5-L122C6

FjordStaking Constructor:

https://github.com/Cyfrin/2024-08-fjord/blob/0312fa9dca29fa7ed9fc432fdcd05545b736575d/src/FjordStaking.sol#L281C5-L303C6

1. Initialization Time Difference:

   • The lastDistribution timestamp for FjordPoints is initialized during its own deployment.

   • The startTime for FjordStaking is initialized subsequently when the staking contract is deployed.

   • Due to separate deployment blocks, there is an inherent slight difference in these timestamps.

2. Epoch Change Discrepancy:

   • Points are distributed based on the lastDistribution timestamp in FjordPoints.

   • Staking logic in FjordStaking checks epochs based on its own startTime.

   • An attacker can stake tokens just before an epoch change in FjordPoints and then unstake immediately after the points are distributed but before FjordStaking registers the epoch change.

3. Potential Exploit:

   • By carefully timing the staking and unstaking operations, an attacker can repeatedly claim points without having their tokens locked for a required epoch duration, thereby gaining unearned rewards.

   • An attacker could strategically exploit the timing discrepancy between the deployment of the FjordPoints and FjordStaking contracts by spamming the Ethereum network to raise gas prices. By doing so, they can intentionally delay the deployment of the FjordStaking contract after the FjordPoints contract has already been deployed. This artificial delay extends the window during which the FjordPoints contract's epoch can change before the staked tokens are recognized by the FjordStaking contract.

Impact

This vulnerability allows an attacker to claim unearned rewards by exploiting the timing discrepancy between the FjordPoints contract and the FjordStaking contract epoch start times.

POC

Logs

Tools Used

Foundry

Recommendations

1. Initialize lastDistribution during setStakingContract:

   • Instead of setting lastDistribution in the FjordPoints constructor, set it during the setStakingContract call.

2. Synchronize Epoch Start Times:

   • Retrieve the start time directly from the FjordStaking contract within the setStakingContract function. This ensures that both contracts are aligned in terms of epoch timing.