# ConcentratedLiquidityPool.burn() Wrong implementation

ConcentratedLiquidityPool.burn() subtracted only fees from reserves instead of burned amounts, desyncing reserves from actual balances and breaking swap() and mint().

- Payout: Audit contest
- Severity: high
- Program: Sushi
- Found by: WatchPug
- Disclosed: 2021-11-30
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-09-sushitrident-2-findings/issues/24
- Library page: https://bugbountylibrary.com/r/c4%3A2021-09-sushitrident-2%3AH-10
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error

**Target:** ConcentratedLiquidityPool.sol burn() reserve accounting
**Root cause:** burn() updates reserve0/reserve1 by subtracting only the fee amounts rather than the full burned amount0/amount1, so reserves no longer match the pool's actual bento share balances.
**Steps:**
1. Read ConcentratedLiquidityPool.sol#L263-L267 burn() logic
2. Observe reserves decremented by amount0fees/amount1fees instead of amount0/amount1
3. Call burn() to remove liquidity; reserves stay larger than actual balances
4. Subsequent swap()/mint() compute against stale inflated reserves and malfunction
**How found:** Code review of burn() accounting: noticed reserves were reduced only by fees rather than the burned amounts, leaving reserve0/reserve1 inconsistent with balance0/balance1.
**Insight:** In AMM accounting, verify every reserve mutation subtracts the full token amount leaving the pool, not just the fee component; a fee-only decrement silently inflates reserves and corrupts all downstream pricing math.