# No slippage control when minting and redeeming FPS

Frankencoin Equity mint/redeem of FPS lacks slippage limits, letting an MEV bot sandwich a user's mint to profit 310 FPS and 258 ZCHF.

- Payout: Contest reward
- Severity: medium
- Program: Frankencoin
- Credited: cccz
- Disclosed: 2023-06-09
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-04-frankencoin-findings/issues/396
- Library page: https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:chained vuln:business-logic

**Target:** Equity.sol mint/redeem FPS functions
**Root cause:** mint() and redeem() compute FPS/ZCHF amounts from the pool's current reserve with no minFPSout/minZCHFout parameter, so the caller accepts whatever price results after their tx is ordered.
**Steps:**
1. Pool starts at 1000 ZCHF reserve, 1000 FPS supply.
2. Alice submits mint with 4000 ZCHF expecting ~710 FPS.
3. Bob front-runs: mints 4000 ZCHF, gets 710 FPS, reserve=5000, supply=1710.
4. Alice's tx executes: reserve=9000, supply=2080, she receives only 370 FPS.
5. Bob redeems 400 FPS: supply drops to 1680, reserve to ~4742, he receives ~4258 ZCHF.
6. Bob nets +310 FPS and +258 ZCHF at Alice's expense.
**How found:** Code review of Equity.mint/redeem noting the absence of a min-output parameter combined with a reserve-dependent (cube-root) pricing formula, then modeling a sandwich numerically.
**Exploitation:** MEV searcher observes victim mint in mempool, front-runs with an equal/larger mint to move the cubic price, lets victim's mint execute at worse rate, then back-runs by redeeming to capture the price difference.
**Insight:** Any AMM-style mint/redeem priced off contract reserve without a user-supplied min-out is sandwichable; check bonding-curve functions for missing slippage params, especially where price is a nonlinear function of reserve.