# Wrong liquidity units calculation

Vader Protocol's calcLiquidityUnits misapplied operator precedence versus spec, minting wrong LP units and enabling economic exploitation via redeem mismatch.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Disclosed: 2021-06-14
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-04-vader-findings/issues/204
- Library page: https://bugbountylibrary.com/r/c4%3A2021-04-vader%3AH-08
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Utils.calcLiquidityUnits LP minting math
**Root cause:** Implementation computes `((P * part1) + part2) / part3 * slipAdjustments` instead of spec's `P * (part1 + part2) / part3 * slipAdjustments`, so P is not distributed over part2 and associativity on P*part1 is wrong.
**Steps:**
1. Compare spec formula `units = (P (a B + A b))/(2 A B) * slipAdjustment` against `Utils.calcLiquidityUnits`.
2. Observe code computes `((P * part1) + part2) / part3 * slipAdjustments`.
3. Note part2 is not multiplied by P and P*part1 grouping differs from spec.
4. Mint LP via addLiquidity, then redeem; returned tokens differ from initial deposit, confirming mismatch.
**How found:** Code-reading comparison of the spec's LP unit formula against the implementation, spotting operator precedence and missing multiplication by P.
**Exploitation:** Attacker adds liquidity to receive mispriced LP units, then redeems them to extract more underlying tokens than deposited, draining pool value.
**Insight:** When a spec formula is transcribed into code, check operator precedence and distribution of multiplicative factors across summed terms; a single misplaced parenthesis in LP math creates a redeem/deposit arbitrage.