# Insufficient check on asset decimals input in create_pool allows malicious pool to be created with invalid swap results

Permissionless create_pool accepts arbitrary asset decimals, so a malicious stableswap pool scales amounts wrongly, breaking swap and slippage math and enabling sandwiching of liquidity providers.

- 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-05
- Library page: https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AM-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:chained technique:source-review vuln:accounting-error vuln:business-logic

**Target:** CosmWasm pool-manager create_pool / stableswap compute_swap
**Root cause:** create_pool only checks that asset_decimals length matches asset_denoms, never validating decimals against actual token metadata; wrong decimals are persisted and used to scale offer_pool/ask_pool/offer_amount in compute_swap.
**Steps:**
1. Call `create_pool` with valid `asset_denoms` but incorrect `asset_decimals` values (length-matched) for a `PoolType::StableSwap` pool.
2. Pool is saved with the bogus decimals in `PoolInfo.asset_decimals`.
3. Any swap or `provide_liquidity` on that pool identifier calls `compute_swap`, which scales amounts via `Decimal256::decimal_with_precision(..., offer_precision/ask_precision)`.
4. Observe incorrect `calculate_stableswap_y` output and incorrect slippage computation for liquidity additions.
**How found:** Code review of create_pool noticed the only validation is array-length equality; traced asset_decimals into PoolInfo and then into compute_swap's decimal_with_precision scaling, hypothesizing wrong decimals yield invalid stableswap results and broken slippage.
**Exploitation:** Malicious pool creator deploys a stableswap pool with wrong decimals; sophisticated users sandwich less sophisticated users swapping/providing liquidity in that pool, since slippage protection is computed on the same wrong scaling and cannot prevent loss.
**Insight:** When a permissionless factory persists user-supplied token metadata (decimals), check whether downstream math and slippage guards reuse that same unvalidated value—if so, slippage protection silently fails and sandwiching becomes viable.