In the BaseGauge::updatePeriod function scheduling error where new reward/voting periods are initialized with double the intended duration (14 days instead of 7 days). This miscalculation creates systemic misalignment of protocol cycles, disrupting time-sensitive operations including reward distributions, voting periods, and boost recalculations.
When the CONTROLLER_ROLE calls the updatePeriod function, it updates the period and calculates new weights. However, the logic incorrectly sets nextPeriodStart, causing the new period to start two intervals later instead of one. According to the intended design, nextPeriodStart should be set 7 days later as defined in the getPeriodDuration function.
Assumptions:
block.timestamp (currentTime) = 1739050128
periodDuration = 604800 seconds (7 days)
Calculation:
Result:
Time gap = 1740259728 - 1739050128 = 1209600 seconds, which equals 14 days.
Assumptions:
periodDuration = 2592000 seconds (30 days)
Calculation:
Result:
Time gap = 1744234128 - 1739050128 = 5184000 seconds, which equals 60 days.
Due to the miscalculation, the protocol ends up doubling the intended period duration (e.g., 14 days instead of 7, 60 days instead of 30). This leads to:
Delayed reward distributions.
Misaligned voting periods.
Inaccurate boost recalculations.
The error causes the gauge to update its cycle boundaries twice as late as intended, so instead of a 7-day cycle, the gauge’s internal state resets every 14 days. This misalignment delays reward rate adjustments, disrupts the voting period and boost calculations (which depend on timely, averaged weight data), and can lead to unpredictable reward accrual and distribution, ultimately compromising the protocol’s operational consistency.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.