Broad Jetblack Alligator
Medium
The rounding down of time calculations will cause potential rounding errors for time-sensitive operations, as transactions near week boundaries may be incorrectly assigned to the previous week, leading to delayed or missed actions.
- The `block.timestamp` represents the current time in seconds (the number of seconds since the Unix epoch).
- Dividing `block.timestamp` by `1 weeks` gives the number of full weeks since the Unix epoch (this is integer division, so any remainder is discarded).
- Multiplying the result by `1 weeks` rounds the timestamp down to the start of the current week.
This is meant to align activePeriod with the beginning of a week, so certain contract actions can be performed based on weekly intervals.
https://github.com/sherlock-audit/2024-10-axion/blob/d75df3636ea28dd627d548d5d473c5d5477b0dc6/solidly-utils/contracts/MasterUtils.sol#L71 https://github.com/sherlock-audit/2024-10-axion/blob/d75df3636ea28dd627d548d5d473c5d5477b0dc6/solidly-utils/contracts/MasterUtils.sol#L135
No response
No response
imagine block.timestamp is one second before the start of a new week. For instance:
- Let’s say block.timestamp = 1,209,599 seconds (2 weeks minus 1 second).
- Dividing this by 1 week gives:
1,209,599 / 604,800 = 1
- Multiplying back by 1 week results in:
1 * 604,800 = 604,800
- This rounds the timestamp down to the previous week, even though we're almost in the next week.
the contract would still consider the current time as part of the previous week, even though we're extremely close to the next week.
No response
No response