# Vulnerable liquidity slippage calculation doesn’t ensure slippage protection due to unscaled assets sum

MANTRA stableswap slippage check sums unscaled asset amounts, so deposits with different decimals produce identical totals and bypass slippage protection.

- Payout: Audit contest
- Severity: medium
- Program: MANTRA
- Credited: oakcobalt
- Disclosed: 2025-03-31
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-11-mantra-dex#m-19
- Library page: https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AM-19
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** CosmWasm pool-manager stableswap provide_liquidity slippage assertion
**Root cause:** assert_slippage_tolerance sums raw deposit and pool coin amounts without normalizing to a common decimal scale, so assets of differing decimals yield meaningless totals and ratios.
**Steps:**
1. Call provide_liquidity on a stableswap pool with slippage_tolerance set.
2. Observe helpers::assert_slippage_tolerance sums deposits and pools via fold without scaling.
3. Compare deposits (1000000 usdc + 1e18 dai) vs (1e18 usdc + 1e6 dai): both produce identical deposits_total.
4. pool_ratio/deposit_ratio comparison passes despite vastly different real value deposited, bypassing slippage protection.
**How found:** Code review of the stableswap branch in assert_slippage_tolerance; noticed the fold sums raw Uint256 amounts and reasoned that differing decimals make the ratio comparison invalid.
**Exploitation:** Liquidity provider submits a deposit with skewed decimal amounts; the unscaled sum makes deposit_ratio appear acceptable, so the pool accepts a deposit whose real value deviates far beyond the stated slippage tolerance, harming the depositor or pool.
**Insight:** In multi-asset AMM math, always check whether sums/ratios normalize decimals per asset; a plain fold over coin amounts silently treats 1e6 USDC and 1e18 DAI as comparable.