# The first lp provider can destroy the pool

First LP can deposit 1 wei to set an extreme pool rate, causing overflow in VaderMath and permanently blocking all subsequent deposits.

- Payout: Audit contest
- Severity: medium
- Program: Vader Protocol
- Found by: jonah1005
- Disclosed: 2022-02-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-11-vader-findings/issues/109
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AM-09
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** DEX liquidity pool addLiquidity / VaderMath
**Root cause:** First LP's deposit sets the pool unit rate with no minimum; a 1-wei deposit yields a huge poolUnitFactor so later deposits overflow in VaderMath's multiplication.
**Steps:**
1. Attacker back-runs `setTokenSupport` for a new pool.
2. Calls `router.addLiquidity(dai, vader, 1, 10**18, user, 10**18)` as first LP, receiving 10**18 liquidity units and setting an extreme rate.
3. Any subsequent `addLiquidity` with normal amounts reverts due to overflow in `((totalPoolUnits * poolUnitFactor) / denominator) * slip`.
**How found:** Code review of VaderMath multiplication and reasoning about first-depositor rate-setting with no minimum deposit.
**Exploitation:** Attacker becomes first LP with a 1-wei deposit, fixing an extreme pool rate; all later depositors' addLiquidity calls revert on overflow, DoSing the pool.
**Insight:** First-depositor share/rate initialization without a minimum lets an attacker pin an extreme poolUnitFactor; check whether downstream math (totalPoolUnits * factor) can overflow for normal-sized later deposits.