# Early user can break addLiquidity

First depositor mints 1 wei of liquidity, inflating share price so later addLiquidity mints near-zero units, bricking the pool.

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

**Target:** BasePool.sol addLiquidity / calculateLiquidityUnits
**Root cause:** When totalSupply==0, liquidity is set directly to nativeDeposit instead of locking a minimum, so the first minter controls the initial share-to-asset ratio used by calculateLiquidityUnits for all future deposits.
**Steps:**
1. Attacker calls `addLiquidity` with 1 wei USDV as the first depositor, receiving 1 liquidity unit.
2. totalLiquidityUnits becomes 1 and the pool ratio is fixed at 1 unit per 1 wei.
3. Any subsequent `addLiquidity` computes liquidity via `calculateLiquidityUnits`, yielding ~0 units for normal deposits.
4. Future users effectively cannot add liquidity; pool is bricked.
**How found:** Code review of the first-mint branch in BasePool.addLiquidity noting the TODO comment and that totalLiquidityUnits feeds calculateLiquidityUnits for later mints; recognized the classic Uniswap v2 first-depositor inflation pattern.
**Exploitation:** Attacker front-runs the first deposit with a minimal 1 wei deposit to seize the initial share ratio, denying all subsequent liquidity providers from receiving meaningful units.
**Insight:** Any AMM fork that special-cases totalSupply==0 without locking a minimum (e.g. minting to zero address) is vulnerable to first-depositor ratio manipulation; check the initial-mint branch of every pool contract.