# If dt is not updated accurately, timeWeightedWeeklyPositionInRangeConcLiquidity_ might be updated incorrectly

In Canto LiquidityMining, dt is not updated when a tick exits in the next week, causing under-counted time-weighted liquidity and incorrect reward accrual.

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

**Target:** LiquidityMining.sol accrueConcentratedPositionTimeWeightedLiquidity
**Root cause:** In the else branch where tickTracking.exitTimestamp >= nextWeek, dt is left at its initial nextWeek - time value instead of being set to tickActiveEnd - tickActiveStart, so the while-loop iterator advances too far and skips accrual iterations.
**Steps:**
1. Call accrueConcentratedPositionTimeWeightedLiquidity for a position whose tick has enterTimestamp > lastAccrued and exitTimestamp in a later week.
2. Observe dt initialized to nextWeek - time; in the exit-in-next-week else branch dt is not recomputed.
3. time += dt overshoots, reducing loop iterations and under-adding to timeWeightedWeeklyPositionInRangeConcLiquidity_.
4. claimConcentratedRewards then computes rewardsToSend from the understated in-range liquidity.
**How found:** Code reading of the while-loop's dt initialization versus the two exit branches; noticed the if branch updates dt but the else branch does not, then reasoned about tickActiveStart = enterTimestamp > time making dt too large.
**Insight:** When auditing accrual loops that advance a time iterator, check that every branch recomputes the step from the actual accrued interval (tickActiveEnd - tickActiveStart), not from the loop's initial dt; mismatched branches silently skip iterations.