Platform: Code4rena
Start Date: 07/08/2023
Pot Size: $36,500 USDC
Total HM: 11
Participants: 125
Period: 3 days
Judge: alcueca
Total Solo HM: 4
Id: 274
League: ETH
Rank: 5/125
Findings: 1
Award: $2,133.21
🌟 Selected for report: 1
🚀 Solo Findings: 1
🌟 Selected for report: gzeon
2133.2145 USDC - $2,133.21
Discovered by #8
In most other places, locks are created with the end time rounded down to nearest weekly increment using the _floorToWeek function.
// @dev Floors a timestamp to the nearest weekly increment // @param _t Timestamp to floor function _floorToWeek(uint256 _t) internal pure returns (uint256) { return (_t / WEEK) * WEEK; }
However in IncreaseAmount, it is simply set to block.timestamp + LOCKTIME without the rounding:
newLocked.end = block.timestamp + LOCKTIME;
#0 - itsmetechjay
2023-08-09T22:01:11Z
As noted in the README for this audit:
This audit was preceded by a Code4rena Test Coverage competition, which integrates a swarm approach to smart contract unit test coverage.
While auditing was not the purpose of the testing phase, relevant and valuable findings reported during that phase will be considered. Auditors who identified vulnerabilities during the test coverage phase will be eligible for a share of the pot, with H/M findings identified reviewed and judged as solo findings.
As such, C4 staff have added the above finding that was submitted by gzeon on July 26, 2023 at 3:58PM CDT as part of the test coverage competition. Adding a "Medium severity" label as a placeholder, until this can be evaluated by the judge.
#1 - c4-pre-sort
2023-08-12T09:23:08Z
141345 marked the issue as low quality report
#2 - c4-pre-sort
2023-08-14T15:50:03Z
141345 marked the issue as remove high or low quality report
#3 - 141345
2023-08-14T15:51:00Z
Locked.end will affect the delegate/undelegate requirement, such as the following check.
File: src\VotingEscrow.sol 382: require(toLocked.amount > 0, "Delegatee has no lock"); 383: require(toLocked.end > block.timestamp, "Delegatee lock expired"); 384: require(toLocked.end >= fromLocked.end, "Only delegate to longer lock");
#4 - OpenCoreCH
2023-08-16T14:44:51Z
This was discovered during the testing contest and fixed before the audit contest, pasting my comment here for reference:
Good catch, I think that would mess up the _checkpoint logic which implicitly assumes that the lock times are aligned, so will definitely be fixed.
#5 - c4-sponsor
2023-08-16T14:44:56Z
OpenCoreCH marked the issue as sponsor confirmed
#6 - c4-judge
2023-08-22T14:42:13Z
alcueca marked the issue as satisfactory
#7 - alcueca
2023-08-28T15:04:15Z
Impact from sponsor:
These slope changes would not have been applied (neither the user-specific ones, nor the global ones), resulting in wrong slopes. And if many users did this, many slopes would be messed up at some point, leading to wrong votes / relative votes