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: 40/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
The loop the calculate inRangeLiquidityOfPosition
might go above tx gas limit when the liquidity position have a large range (i.e. upperTick - lowerTick is huge). The user would not be able to claim reward.
for (int24 j = lowerTick + 10; j <= upperTick - 10; ++j) { inRangeLiquidityOfPosition += timeWeightedWeeklyPositionInRangeConcLiquidity_[poolIdx][posKey][week][j]; }
One solution is to add a function that allow user to pre-calc inRangeLiquidityOfPosition with pagination.
DoS
#0 - c4-pre-sort
2023-10-09T16:59:21Z
141345 marked the issue as sufficient quality report
#1 - c4-sponsor
2023-10-11T11:01:10Z
OpenCoreCH (sponsor) acknowledged
#2 - OpenCoreCH
2023-10-11T11:02:13Z
Technically true, in practice it is questionable if this will be a large problem, as a user can create Ambient positions (covering the whole range) instead of huge concentrated positions.
#3 - c4-judge
2023-10-18T22:15:22Z
dmvt changed the severity to QA (Quality Assurance)
#4 - c4-judge
2023-10-18T22:52:57Z
dmvt marked the issue as grade-b