Canto Liquidity Mining Protocol - twicek's results

Lines of code

https://github.com/code-423n4/2023-10-canto/blob/40edbe0c9558b478c84336aaad9b9626e5d99f34/canto_ambient/contracts/mixins/LiquidityMining.sol#L94-L133

Vulnerability details

Proof of Concept

If a user neither modifies his position nor claims rewards for a very long time, it might become impossible for him to do any action involving the internal functions accrueAmbientPositionTimeWeightedLiquidity or accrueConcentratedPositionTimeWeightedLiquidity. accrueConcentratedPositionTimeWeightedLiquidity is the more likely to generate this issue:

LiquidityMining.sol#L94-L133

                while (time < block.timestamp && tickTrackingIndex < numTickTracking) {
                    TickTracking memory tickTracking = tickTracking_[poolIdx][i][tickTrackingIndex];
                    uint32 currWeek = uint32((time / WEEK) * WEEK);
                    uint32 nextWeek = uint32(((time + WEEK) / WEEK) * WEEK);
                    uint32 dt = uint32(
                        nextWeek < block.timestamp
                            ? nextWeek - time
                            : block.timestamp - time
                    );
                    uint32 tickActiveStart; // Timestamp to use for the liquidity addition
                    uint32 tickActiveEnd;
                    if (tickTracking.enterTimestamp < nextWeek) {
                        // Tick was active before next week, need to add the liquidity
                        if (tickTracking.enterTimestamp < time) {
                            // Tick was already active when last claim happened, only accrue from last claim timestamp
                            tickActiveStart = time;
                        } else {
                            // Tick has become active this week
                            tickActiveStart = tickTracking.enterTimestamp;
                        }
                        if (tickTracking.exitTimestamp == 0) {
                            // Tick still active, do not increase index because we need to continue from here
                            tickActiveEnd = uint32(nextWeek < block.timestamp ? nextWeek : block.timestamp);
                        } else {
                            // Tick is no longer active
                            if (tickTracking.exitTimestamp < nextWeek) {
                                // Exit was in this week, continue with next tick
                                tickActiveEnd = tickTracking.exitTimestamp;
                                tickTrackingIndex++;
                                dt = tickActiveEnd - tickActiveStart;
                            } else {
                                // Exit was in next week, we need to consider the current tick there (i.e. not increase the index)
                                tickActiveEnd = nextWeek;
                            }
                        }
                        timeWeightedWeeklyPositionInRangeConcLiquidity_[poolIdx][posKey][currWeek][i] +=
                            (tickActiveEnd - tickActiveStart) * liquidity;
                    }
                    time += dt;
                }

In this function, a for loop iterates over each tick, and for each tick a while loop is done for each tick tracking index to calculate its contribution. A tick could have a very large amount of tick tracking indexes to loop over in its while loop if it has not been updated for a very long time for the user position.

Example:

Each time a tick is crossed it will have a new item in its tickTracking_ array. If a user does not change his position for let's say 1 year, hundreds, if not thousands, of entries could be added to tickTracking_. A year later, the user function call might need to do more than 21 (ticks) * 1000 (number of tick tracking items not accrued) = 21000 total iterations for the for + while loop in accrueConcentratedPositionTimeWeightedLiquidity. The cost for such a function call could surpass the 30M gas limit.

Impact

The user funds will be locked in the contract as he will not be able to call the mint or burn function as well as not being able to claim rewards.

Tool used

Manual Review

Recommended Mitigation Steps

Consider splitting the accrual in several calls with a dedicated function or create an admin function that updates inactive accounts before they surpass the 30M gas limit.

Assessed type

DoS