Total supply needs to be greater than zero

Oct 13, 2025 by sorusgentrification.com 34 views

Clean Mustard Aphid: Precision Loss Will Cause Users to Lose Rewards in RewardPerToken Calculation

Introduction

In the world of decentralized finance (DeFi), precision is crucial when it comes to calculating rewards for stakers. However, a recent issue has been discovered in the SymmStaking contract, which can cause significant precision loss, resulting in users losing rewards in the rewardPerToken calculation. In this article, we will delve into the root cause of this issue, its impact, and the mitigation strategies to prevent it.

Summary

The division before multiplication in the rewardPerToken calculation will cause significant precision loss for stakers as the reward distribution will be truncated to zero for small amounts. This issue arises from the fact that the reward calculation performs division before multiplication, causing precision loss.

Root Cause

The root cause of this issue lies in the token/contracts/staking/SymmStaking.sol contract, specifically in the rewardPerToken function (lines 194-202). The reward calculation performs division before multiplication, causing precision loss: (((lastTimeRewardApplicable(_rewardsToken) - rewardState[_rewardsToken].lastUpdated) * rewardState[_rewardsToken].rate * 1e18) / totalSupply).

Internal Pre-conditions

For the precision loss issue to occur, the following internal pre-conditions must be met:

Total supply needs to be greater than zero: The total supply of tokens must be greater than zero for the precision loss issue to occur.
Reward rate needs to be set to a small value: The reward rate must be set to a small value for the precision loss issue to occur.
Time difference needs to be relatively small: The time difference between the last time reward was applicable and the last updated time must be relatively small for the precision loss issue to occur.

External Pre-conditions

No external preconditions are required for the precision loss issue to occur.

Attack Path

The attack path for this issue is as follows:

User stakes a small amount of tokens when totalSupply is large: A user stakes a small amount of tokens when the total supply of tokens is large.
Division before multiplication causes truncation: Due to the division before multiplication, the calculation (time_diff * rate * 1e18) / totalSupply truncates to 0.
PerTokenStored value doesn't increase: Even though rewards should accumulate, the perTokenStored value doesn't increase.
This continues until the numerator becomes large enough to overcome the division truncation: This continues until the numerator becomes large enough to overcome the division truncation.

Impact

The impact of this issue is that stakers suffer an approximate loss of rewards proportional to truncation frequency. Specifically:

Small stakers lose rewards completely: Small stakers lose rewards completely when rate * time_diff < totalSupply/1e18.
Medium stakers receive fewer rewards than entitled: Medium stakers receive fewer rewards than entitled.
Lost rewards remain stuck in the contract: The lost rewards remain stuck in the contract.

Proof of Concept

A proof of concept (PoC) has been created to demonstrate the precision loss issue. The PoC is as follows:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import {Test} from "forge-std/Test.sol";
import {SymmStaking} from "../contracts/staking/SymmStaking.sol";

contract PrecisionLossTest is Test {
    SymmStaking staking;
    address rewardToken = address(1);

    function setUp() public {
        staking = new SymmStaking();
        // Setup staking contract with initial state
    }

    function testPrecisionLoss() public {
        // Setup scenario
        uint256 totalSupply = 1e24; // Large total supply
        uint256 rate = 1e15;        // Small rate
        uint256 timeDiff = 100;     // Small time difference

        // Calculate reward with current implementation
        uint256 badReward = (timeDiff * rate * 1e18) / totalSupply;

        // Calculate reward with corrected order
        uint256 goodReward = (timeDiff * 1e18 * rate) / totalSupply;

        // Verify precision loss
        assertEq(badReward, 0, "Bad implementation truncates to zero");
        assertGt(goodReward, 0, "Correct implementation preserves precision");
    }
}

Mitigation

To mitigate this issue, the following strategies can be implemented:

Reorder mathematical operations: Reorder the mathematical operations to perform multiplication before division:

return rewardState[_rewardsToken].perTokenStored + 
    (((lastTimeRewardApplicable(_rewardsToken) - rewardState[_rewardsToken].lastUpdated) * 1e18)
    * rewardState[_rewardsToken].rate) / totalSupply;

Use higher precision factor: Consider using a higher precision factor than 1e18 for intermediate calculations.
Add minimum rate checks: Add minimum rate checks to prevent extremely small reward rates.
Implement reward accumulation checkpoints: Consider implementing reward accumulation checkpoints to minimize precision loss over time.

By implementing these mitigation strategies, the precision loss issue can be prevented, ensuring that stakers receive their rightful rewards.
Clean Mustard Aphid: Precision Loss Will Cause Users to Lose Rewards in RewardPerToken Calculation - Q&A

Introduction

In our previous article, we discussed the precision loss issue in the SymmStaking contract, which can cause significant precision loss, resulting in users losing rewards in the rewardPerToken calculation. In this article, we will answer some frequently asked questions (FAQs) related to this issue.

Q: What is the root cause of the precision loss issue?

A: The root cause of the precision loss issue lies in the token/contracts/staking/SymmStaking.sol contract, specifically in the rewardPerToken function (lines 194-202). The reward calculation performs division before multiplication, causing precision loss: (((lastTimeRewardApplicable(_rewardsToken) - rewardState[_rewardsToken].lastUpdated) * rewardState[_rewardsToken].rate * 1e18) / totalSupply).

Q: What are the internal pre-conditions for the precision loss issue to occur?

A: For the precision loss issue to occur, the following internal pre-conditions must be met:

Total supply needs to be greater than zero: The total supply of tokens must be greater than zero for the precision loss issue to occur.
Reward rate needs to be set to a small value: The reward rate must be set to a small value for the precision loss issue to occur.
Time difference needs to be relatively small: The time difference between the last time reward was applicable and the last updated time must be relatively small for the precision loss issue to occur.

Q: What are the external pre-conditions for the precision loss issue to occur?

A: No external preconditions are required for the precision loss issue to occur.

Q: What is the impact of the precision loss issue?

A: The impact of this issue is that stakers suffer an approximate loss of rewards proportional to truncation frequency. Specifically:

Small stakers lose rewards completely: Small stakers lose rewards completely when rate * time_diff < totalSupply/1e18.
Medium stakers receive fewer rewards than entitled: Medium stakers receive fewer rewards than entitled.
Lost rewards remain stuck in the contract: The lost rewards remain stuck in the contract.

Q: How can the precision loss issue be mitigated?

A: To mitigate this issue, the following strategies can be implemented:

Reorder mathematical operations: Reorder the mathematical operations to perform multiplication before division:

return rewardState[_rewardsToken].perTokenStored + 
    (((lastTimeRewardApplicable(_rewardsToken) - rewardState[_rewardsToken].lastUpdated) * 1e18)
    * rewardState[_rewardsToken].rate) / totalSupply;

Use higher precision factor: Consider using a higher precision factor than 1e18 for intermediate calculations.
Add minimum rate checks: Add minimum rate checks to prevent extremely small reward rates.
Implement reward accumulation checkpoints: Consider implementing reward accumulation checkpoints to minimize precision loss over time.

Q: What is the proof of concept (PoC) for the precision loss issue?

A: A proof of concept (PoC) has been created to demonstrate the precision loss issue. The PoC is as follows:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import {Test} from "forge-std/Test.sol";
import {SymmStaking} from "../contracts/staking/SymmStaking.sol";

contract PrecisionLossTest is Test {
    SymmStaking staking;
    address rewardToken = address(1);

    function setUp() public {
        staking = new SymmStaking();
        // Setup staking contract with initial state
    }

    function testPrecisionLoss() public {
        // Setup scenario
        uint256 totalSupply = 1e24; // Large total supply
        uint256 rate = 1e15;        // Small rate
        uint256 timeDiff = 100;     // Small time difference

        // Calculate reward with current implementation
        uint256 badReward = (timeDiff * rate * 1e18) / totalSupply;

        // Calculate reward with corrected order
        uint256 goodReward = (timeDiff * 1e18 * rate) / totalSupply;

        // Verify precision loss
        assertEq(badReward, 0, "Bad implementation truncates to zero");
        assertGt(goodReward, 0, "Correct implementation preserves precision");
    }
}

Q: What are the best practices to prevent precision loss issues in the future?

A: To prevent precision loss issues in the future, the following best practices can be followed:

Use higher precision factors: Use higher precision factors than 1e18 for intermediate calculations.
Reorder mathematical operations: Reorder mathematical operations to perform multiplication before division.
Add minimum rate checks: Add minimum rate checks to prevent extremely small reward rates.
Implement reward accumulation checkpoints: Consider implementing reward accumulation checkpoints to minimize precision loss over time.

By following these best practices and implementing the mitigation strategies, the precision loss issue can be prevented, ensuring that stakers receive their rightful rewards.