# ERC5095.mint function calculates slippage incorrectly

ERC5095.mint computes 1% slippage on assets paid rather than shares requested, letting users receive ~2% fewer principal tokens than expected.

- Payout: Contest reward
- Severity: medium
- Program: Illuminate
- Credited: pashov
- Disclosed: 2022-10-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-illuminate-judging/issues/31
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-illuminate%3AM-16
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** ERC5095.mint / Marketplace.sellUnderlying
**Root cause:** Slippage floor is derived from the assets amount (base tokens paid) instead of the shares amount the user requested, so the minimum-out is set too low relative to shares.
**Steps:**
1. Call `ERC5095.mint(r, 1000)` requesting 1000 principal shares
2. `previewMint(1000)` returns assets=990 base tokens
3. mint transfers 990 underlying and calls `sellUnderlying(underlying, maturity, 990, 990 - 990/100 = 980.1)`
4. Marketplace can return as few as 980.1 principal tokens, ~2% below the 1000 requested
**How found:** Code review of mint's slippage parameter, noticing the min-out uses `assets` while the user's intent is denominated in shares `s`.
**Exploitation:** A user minting shares during unfavorable price movement receives up to ~2% fewer principal tokens than intended because the min-out floor is computed from assets not shares; value leaks to the counterparty/trader.
**Insight:** When a function's user-facing input is in one unit (shares) but slippage is computed on an intermediate converted unit (assets), the floor is wrong by the conversion ratio; always anchor slippage to the unit the user specified.