Core Contracts

Summary

The flaw lies in the calculation of the next period's start time. The code computes nextPeriodStart as:

uint256 nextPeriodStart = ((currentTime / periodDuration) + 2) * periodDuration;

->

This formula advances the period boundary by two full periods from the quotient of currentTime divided by periodDuration, instead of advancing by just one period.

Vulnerability Details

The error originates from adding 2 to (currentTime / periodDuration) rather than adding 1. The intended logic (as seen in the contract constructor) computes the next period as:

uint256 nextPeriodStart = ((currentTime / periodDuration) + 2) * periodDuration;

By adding 2 in updatePeriod, the code mistakenly skips one period's duration, causing the next period to be set too far in the future.

Impact

This inaccuracy of period calculation will have several major impacts on the protocol :-

-> Creation of voting period if future leaving protocol with no voting period means users are not able to vote on proposals
->Every calculation based upon factors of period will gets effected like Avgweight calculation with further is base of many other calculation , a wide range of features will gets affected

POC

Assume periodDuration is 7 days (i.e., 604800 seconds) and periodState.periodStartTime is aligned with period boundaries (e.g., 0 seconds). Then:

• The current period ends at:

  periodEnd = 0 + 604800 = 604800 seconds.

• If updatePeriod is called just after the period ends, say at currentTime = 604801 seconds:

  currentTime / periodDuration = 604801 / 604800 = 1 (integer division).

• The code calculates nextPeriodStart as:

  ((1) + 2) * 604800 = 3 * 604800 = 1814400 seconds,

  which corresponds to day 21.

The correct next period start should be:

periodEnd + periodDuration = 604800 + 604800 = 1209600 seconds,

which is day 14. This means a full period (7 days) is skipped, leaving an unaccounted gap between day 7 and day 21.

Recommendations

To resolve the issue, adjust the nextPeriodStart calculation so that the new period begins immediately after the current period ends. For example, change the code to:

uint256 nextPeriodStart = ((currentTime / periodDuration) + 1) * periodDuration;

Alternatively, you can compute it directly from periodEnd:

uint256 nextPeriodStart = periodEnd + periodDuration;

Both approaches ensure that the next period starts at the correct time without skipping a period.