# Minting and burning synths exposes users to unlimited slippage

VaderPool.mintSynth lacks a minimum-output parameter, letting a frontrunner skew pool reserves so users mint/burn synths at arbitrarily bad rates.

- 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/2
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AH-01
- 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.mintSynth / burnSynth (DEX pool synth minting)
**Root cause:** mintSynth and burnSynth compute synth amounts from pool reserves but accept no minimum-output argument, so reserve manipulation directly sets the user's exchange rate.
**Steps:**
1. User calls `mintSynth(nativeDeposit)` sending native asset to pool.
2. Attacker frontruns by swapping to skew pool reserves so foreignAsset appears overvalued.
3. User's mint executes at manipulated rate, receiving synths worth far less than nativeDeposit.
4. Attacker backruns to restore reserves and capture the difference.
5. Reverse manipulation applies to burnSynth to reduce nativeAsset received.
**How found:** Code review of mintSynth noting the absence of a minimum-synth-out parameter, making it equivalent to a swap without slippage limit.
**Exploitation:** Sandwich: frontrun a victim's mintSynth/burnSynth with a swap that skews reserves, let the victim's unprotected mint/burn execute at the distorted price, then reverse the swap to profit the delta.
**Insight:** Any mint/burn/redeem path that prices off pool reserves but omits a min-out parameter is a sandwich target even if it isn't literally a swap; check every reserve-derived conversion for user-supplied slippage bounds.