# Accrued liquidity can be lost and never be recovered for a given tick period. 

LiquidityMining.accrueConcentratedPositionTimeWeightedLiquidity fails to increment tickTrackingIndex when exitTimestamp equals nextWeek, permanently losing accrued liquidity rewards for that tick period.

- Payout: Contest reward
- Severity: medium
- Program: Canto
- Credited: Satyam\_Sharma
- Disclosed: 2023-11-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-10-canto-findings/issues/186
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-canto%3AM-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** LiquidityMining.sol accrueConcentratedPositionTimeWeightedLiquidity
**Root cause:** The condition `tickTracking.exitTimestamp < nextWeek` is strict, so when exitTimestamp equals nextWeek the else branch sets tickActiveEnd=nextWeek without incrementing tickTrackingIndex, skipping accrual for that tick period.
**Steps:**
1. User exits concentrated liquidity position exactly at nextWeek timestamp, setting tickTracking.exitTimestamp == nextWeek.
2. Later accrueConcentratedPositionTimeWeightedLiquidity runs; `tickTracking.exitTimestamp < nextWeek` is false.
3. Else branch sets tickActiveEnd = nextWeek and does not increment tickTrackingIndex.
4. Tick period ends without accruing; tickTrackingIndexAccruedUpTo_ not advanced, rewards for that period lost.
**How found:** Code reading of the accrue function's branch logic; noticed strict `<` comparison and reasoned about the equality edge case where exitTimestamp == nextWeek.
**Insight:** When auditing time-weighted accrual loops, check boundary comparisons (`<` vs `<=`) at period boundaries where an index increment is gated by the comparison; equality cases can silently skip accrual.