# Extend lock period should never result in a decrease of overall rewards (`total length of locked period * shares`)

extendLock() recomputes shares from remaining time, so extending a near-expiry lock burns shares and reduces total rewards by up to 12.5%.

- Payout: Contest reward
- Severity: high
- Program: Merit Circle
- Credited: WATCHPUG
- Disclosed: 2022-10-14
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-10-merit-circle-judging/issues/109
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-merit-circle%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** TimeLockPool.sol extendLock() staking contract
**Root cause:** extendLock() computes new duration as remaining time plus increase and mints/burns shares to match the new multiplier, so a short extension near expiry lowers the multiplier and burns previously minted shares.
**Steps:**
1. Alice deposits 100 $MC with 1-year lock, receives 200 shares (200% multiplier).
2. 6 months later she calls `extendLock(depositId, MIN_LOCK_DURATION)` (10 minutes).
3. New duration = remaining 6 months + 10 min, multiplier drops from 200% to ~150%.
4. Contract burns ~50 shares; total rewards become 200*6mo + 150*6mo vs 200*12mo, a 12.5% loss.
**How found:** Code review of extendLock() share recalculation: noticed new duration uses remaining time plus increase rather than original duration plus increase, so extending near expiry reduces the multiplier and burns shares.
**Insight:** When a staking contract recomputes shares from remaining lock time on extension, check whether a small extension near expiry can lower the multiplier and burn existing shares; test boundary cases with MIN_LOCK_DURATION.