Canto Liquidity Mining Protocol - orion's results

Execution layer for original work.

General Information

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

Canto

Findings Distribution

Researcher Performance

Rank: 41/62

Findings: 1

Award: $4.94

QA:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

4.9369 USDC - $4.94

Labels

bug
grade-b
QA (Quality Assurance)
sufficient quality report
Q-10

External Links

Lines of code

https://github.com/code-423n4/2023-10-canto/blob/main/canto_ambient/contracts/mixins/LiquidityMining.sol#L130

Vulnerability details

Impact

LiquidityMining.accrueConcentratedPositionTimeWeightedLiquidity may unintentionally reverts and make transactions does not succeed

Proof of Concept

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

Tools Used

Manual review

In lines 123, and 130 check if tickActiveEnd > tickActiveStart then make the substraction, otherwise return 1 or 0 for the timeWeightedWeeklyPositionInRangeConcLiquidity_ definition

Assessed type

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

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter