Platform: Code4rena
Start Date: 03/10/2023
Pot Size: $24,500 USDC
Total HM: 6
Participants: 62
Period: 3 days
Judge: LSDan
Total Solo HM: 3
Id: 288
League: ETH
Rank: 41/62
Findings: 1
Award: $4.94
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: adriro
Also found by: 0x3b, 0xAadi, 0xDING99YA, 0xTheC0der, 0xWaitress, 0xdice91, 100su, 3docSec, BRONZEDISC, BoRonGod, Eurovickk, GKBG, HChang26, IceBear, JP_Courses, MatricksDeCoder, Mike_Bello90, SovaSlava, Topmark, albahaca, cookedcookee, gzeon, hunter_w3b, kutugu, lukejohn, marqymarq10, matrix_0wl, orion, pep7siup, radev_sw, sces60107, taner2344, tpiliposian, wahedtalash77, xAriextz, zpan
4.9369 USDC - $4.94
LiquidityMining.accrueConcentratedPositionTimeWeightedLiquidity may unintentionally reverts and make transactions does not succeed
The LiquidityMining.accrueConcentratedPositionTimeWeightedLiquidity function calculates the concentrated position liquidity for specific pool, the logic however under some special conditions may reverts unintentionally via the EVM under/overflow protection, the function at some point subtracts tickActiveStart
from tickActiveEnd
at line 160
(tickActiveEnd - tickActiveStart) * liquidity;
For this situation to be met, the following conditions should met :
1/ Line 105 : tickTracking.enterTimestamp < nextWeek (nextWeek = uint32(((time + WEEK) / WEEK) * WEEK))
2/ Line 107 : tickTracking.enterTimestamp < time , here the tickActiveStart
variant will be : tickActiveStart = time;
3/ Line 114 : then (tickTracking.exitTimestamp > 0) will meet not met, will then be passed to the else condition at line 117 which later be forwarded to the condition (tickTracking.exitTimestamp < nextWeek), when this won't met the tickActiveEnd
variable will be tickActiveEnd = nextWeek;
as nextWeek
here is uint32(((time + WEEK) / WEEK) * WEEK);
Under this situation the tickActiveEnd
variant is designed to be actually lower than tickActiveStart, but eventually the (tickActiveEnd - tickActiveStart) * liquidity;
condition will become so more like :
uint32(((time + WEEK) / WEEK) * WEEK) - (time) * liquidity;
That condition will underflows thus the LiquidityMining.accrueConcentratedPositionTimeWeightedLiquidity will reverts
Due to the shortage of time I wasn't be able to make a clear PoC, to make a work around for this situation to meet
Manual review
In lines 123, and 130 check if tickActiveEnd > tickActiveStart
then make the substraction, otherwise return 1 or 0 for the timeWeightedWeeklyPositionInRangeConcLiquidity_ definition
Error
#0 - c4-pre-sort
2023-10-09T17:21:52Z
141345 marked the issue as sufficient quality report
#1 - c4-judge
2023-10-18T23:01:13Z
dmvt marked the issue as grade-b