# VaderPoolV2.mintFungible exposes users to unlimited slippage

VaderPoolV2.mintFungible lacks a minimum-LP-units parameter, letting frontrunners manipulate reserves so LPs receive fewer liquidity units and lose up to 100% of provided value.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Found by: TomFrenchBlockchain
- Disclosed: 2022-02-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-11-vader-findings/issues/248
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AH-29
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** VaderPoolV2.mintFungible liquidity provision function
**Root cause:** mintFungible computes minted LP units from current pool reserves but offers no user-specified minimum LP units, so reserve manipulation between submission and execution changes the mint amount.
**Steps:**
1. LP calls `mintFungible` providing mostly `nativeAsset` and little `foreignAsset`
2. Attacker frontruns by selling large `nativeAsset` into the pool, devaluing it
3. LP's tx executes, minting fewer LP units than fair value
4. Attacker reverses the trade, restoring reserves and pocketing the LP's value
**How found:** Code review of mintFungible noting absence of a min-amount parameter while mint amount derives from manipulable reserves.
**Exploitation:** Attacker observes pending mintFungible tx, sandwiches it: dump nativeAsset to skew reserves, let LP mint at unfavorable ratio, then buy back to restore reserves and capture the difference.
**Insight:** When a deposit/mint function derives share amounts from live reserves, check whether the caller can bound the output; missing min-shares is a sandwichable slippage hole even if the ratio math is correct.