# `increaseLock()` should read `userDeposit[_receiver]` instead of `depositsOf[_msgSender()]`

increaseLock() read the caller's deposit instead of the receiver's, letting a receiver mint up to 5x more shares than their lock duration warranted.

- Payout: Contest reward
- Severity: high
- Program: Merit Circle
- Credited: HonorLt
- Disclosed: 2022-10-14
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-10-merit-circle-judging/issues/102
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-merit-circle%3AH-2
- 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 increaseLock() in merit-liquidity-mining
**Root cause:** increaseLock() loads userDeposit from depositsOf[_msgSender()][_depositId] instead of depositsOf[_receiver][_depositId], so expiry check and remainingDuration are computed from the wrong account's lock.
**Steps:**
1. Call `increaseLock(_depositId, _receiver, _amount)` where `_receiver` has a deposit with short remainingDuration (e.g. 10 min) and caller has a deposit with same `_depositId` but long remainingDuration (e.g. 4 years).
2. Observe L203 loads `depositsOf[_msgSender()][_depositId]` as userDeposit.
3. Expiry check L206-208 and remainingDuration L213 use caller's duration.
4. mintAmount at L215 computed with caller's multiplier, minted to `_receiver` — up to 5x expected shares.
**How found:** Code reading of increaseLock(): noticed userDeposit sourced from _msgSender() while the function's beneficiary is _receiver, and that remainingDuration feeds the multiplier.
**Exploitation:** Attacker with a long-duration deposit at a given depositId calls increaseLock targeting a receiver whose deposit at the same id has little time left, causing excess shares to be minted to the receiver; reverse case mints fewer shares.
**Insight:** In functions taking a separate _receiver/_beneficiary, audit every state read used for accounting — msgSender-keyed lookups silently substitute the caller's position for the beneficiary's, inflating multipliers or bypassing expiry checks.