# Malicious users can provide liquidity on behalf of others to keep others in the liquidity cooldown

AlgebraPool.mint lets anyone add liquidity to another user's position, resetting lastLiquidityAddTimestamp and indefinitely blocking that user from burning liquidity.

- Payout: Contest reward
- Severity: high
- Program: QuickSwap
- Credited: cccz
- Disclosed: 2023-12-01
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-quickswap-findings/issues/70
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-quickswap%3AH-01
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** AlgebraPool DEX contract (mint/burn liquidity)
**Root cause:** mint accepts an arbitrary recipient and updates that position's lastLiquidityAddTimestamp; burn requires elapsed time >= liquidityCooldown since that timestamp, so third-party mints reset the victim's cooldown.
**Steps:**
1. Victim holds a position in AlgebraPool with liquidityCooldown > 0 (max 1 day).
2. Attacker calls `mint(sender=attacker, recipient=victim, bottomTick, topTick, liquidityDesired=1, data)` repeatedly.
3. Each call sets victim position's lastLiquidityAddTimestamp = block.timestamp.
4. Victim calls `burn(...)`; require((_blockTimestamp() - lastLiquidityAddTimestamp) >= _liquidityCooldown) reverts.
5. Repeat mint before each cooldown expiry to lock victim's liquidity indefinitely.
**How found:** Code review of mint's recipient parameter and the burn cooldown check on lastLiquidityAddTimestamp; noticed recipient is caller-controlled and timestamp is per-position.
**Exploitation:** Attacker spends minimal liquidity per mint to grief a targeted LP, preventing withdrawal of funds for as long as they keep refreshing the timestamp; no direct profit, funds locked in pool.
**Insight:** When a cooldown/timelock timestamp is stored per-position, check whether any external caller can write that timestamp for a position they don't own (e.g. via a recipient/onBehalfOf parameter) — that turns a safety delay into a griefing lock.