# mintSynth() and burnSynth() can be front run

mintSynth() and burnSynth() price synth issuance/redemption off pool reserves with no slippage parameter, letting attackers front-run large mints/burns to profit from price impact.

- 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/209
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AH-22
- 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.sol mintSynth/burnSynth synth issuance and redemption
**Root cause:** mintSynth() and burnSynth() compute synth amounts from current pool reserves and move the price, but expose no minAmountOut/maxAmountIn slippage bound, so the caller accepts whatever price the pool is at when the tx lands.
**Steps:**
1. Attacker observes a pending large mintSynth() or burnSynth() tx in the mempool.
2. Attacker front-runs by trading in the same pool to shift reserves/price in their favor.
3. Victim's mint/burn executes at the manipulated price, creating further price impact.
4. Attacker back-runs to unwind the position and capture the difference.
**How found:** Code review of mintSynth()/burnSynth() noting they price off pool reserves and create price impact proportional to volume, while lacking any slippage parameter — a classic missing-slippage observation.
**Exploitation:** Sandwich: front-run trade moves pool price against the victim's large mint/burn, victim executes with no slippage protection, attacker reverses the trade afterward to realize profit from the induced price impact.
**Insight:** Any function that prices an issuance/redemption off AMM reserves and moves price must expose a user-supplied min-out/max-in bound; grep for mint/burn/deposit/redeem paths that read reserves but lack a slippage argument.