# Incorrect slippage_tolerance handling in stableswap provide_liquidty function

Stableswap provide_liquidity only checks one side of the deposit/pool ratio, so with slippage_tolerance=0 depositors can still eat large slippage and leak value.

- Payout: Audit contest
- Severity: high
- Program: MANTRA
- Found by: carrotsmuggler
- Disclosed: 2025-03-31
- Write-up quality: 7/10
- Original: https://code4rena.com/reports/2024-11-mantra-dex#h-10
- Library page: https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AH-10
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** CosmWasm DEX pool-manager provide_liquidity / assert_slippage_tolerance
**Root cause:** Stableswap slippage assertion only checks pool_ratio * (1-tol) > deposit_ratio, missing the inverse comparison, so deposits with deposit_ratio > pool_ratio bypass the tolerance entirely.
**Steps:**
1. Create stableswap pool (amp=100) with 1e6 uwhale + 2e6 uluna, minting 2997146 LP.
2. Call provide_liquidity with 1e4 uwhale + 1e5 uluna and slippage_tolerance=0.
3. Observe pool_ratio=1.00101 < deposit_ratio=1.00272, so assert_slippage_tolerance passes.
4. Show that even receiving only 108000 LP (1.55% loss) still passes since deposit_ratio > pool_ratio.
**How found:** Code review comparing the constant-product two-sided ratio check against the stableswap single-sided check in helpers.rs, then reasoning about the slippage_tolerance=0 edge case and confirming with a POC.
**Exploitation:** Depositor (or MEV/rounding manipulation) adds liquidity in a composition where deposit_ratio exceeds pool_ratio; the one-sided check passes regardless of how few LP tokens are minted, leaking value from the depositor.
**Insight:** When a protocol reimplements a safety check per pool type, diff the branches: asymmetric inequality checks (only one direction of a ratio) silently disable the guard for half the input space.