Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Precision Loss in `nextPeriod` Calculation Due to Division Before Multiplication in `BaseGauge::constructor`

auditbyte

Summary

The calculation of nextPeriod in the BaseGauge.sol constructor performs division before multiplication, which can lead to an unnecessary precision loss. This issue arises from integer division in Solidity, where decimal values are truncated instead of rounded, potentially causing period misalignment.

Vulnerability Details

In the constructor below:

constructor(
address _rewardToken,
address _stakingToken,
address _controller,
uint256 _maxEmission,
uint256 _periodDuration
) {
rewardToken = IERC20(_rewardToken);
stakingToken = IERC20(_stakingToken);
controller = _controller;
// Initialize roles
_grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
_grantRole(CONTROLLER_ROLE, _controller);
// Initialize boost parameters
boostState.maxBoost = 25000; // 2.5x
boostState.minBoost = 1e18;
boostState.boostWindow = 7 days;
​
uint256 currentTime = block.timestamp;
uint256 nextPeriod = ((currentTime / _periodDuration) * _periodDuration) + _periodDuration;
// Initialize period state
periodState.periodStartTime = nextPeriod;
periodState.emission = _maxEmission;
TimeWeightedAverage.createPeriod(
periodState.votingPeriod,
nextPeriod,
_periodDuration,
0,
10000 // VOTE_PRECISION
);
}

In the calculation:

uint256 nextPeriod = ((currentTime / _periodDuration) * _periodDuration) + _periodDuration;

Here, currentTime / _periodDuration performs integer division, which truncates any remainder. This truncated value is then multiplied by _periodDuration, potentially leading to a loss of precision. For example:

  • If currentTime = 100 and _periodDuration = 30, then currentTime / _periodDuration = 3 (truncating the remainder 10).

  • The calculation becomes 3 * 30 + 30 = 120, which is correct in this case.

  • However, if currentTime = 95 and _periodDuration = 30, then currentTime / _periodDuration = 3 (truncating the remainder 5).
    The calculation becomes 3 * 30 + 30 = 120, which skips the expected 90 and jumps to 120.

Impact

  • The period start time might be slightly off from the intended schedule, causing misalignment in emissions or voting periods.

  • Small misalignments could compound over time, leading to larger discrepancies in later periods.

Tools Used

Manual code review

Recommendations

Reorder the Calculation to Avoid Precision Loss

Updates

Lead Judging Commences

inallhonesty Lead Judge 3 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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