# In edge cases, create_pool can either be reverted or allow user underpay fees

MANTRA pool-manager fee validation uses strict equality and .any() instead of .all(), letting users underpay tokenfactory denom creation fees or causing create_pool to revert.

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

**Target:** CosmWasm pool-manager contract create_pool fee validation
**Root cause:** validate_fees_are_paid uses strict equality on pool fee amount and iter().any() over denom_creation_fee, so when the pool fee denom overlaps a tokenfactory fee denom, paying all fees reverts and paying only one denom underpays.
**Steps:**
1. Configure denom_creation_fee with multiple coins, one matching pool_creation_fee.denom.
2. Call create_pool sending pool_creation_fee + all denom_creation_fee coins -> strict equality fails, tx reverts.
3. Call create_pool sending pool_creation_fee + only one non-pool denom_creation coin -> .any() passes, underpaying tokenfactory fees.
**How found:** Code review of validate_fees_are_paid comparing against CosmWasm tokenfactory semantics (SafeSub requires all denom creation fees paid), spotting strict equality and .any() vs .all() mismatch.
**Exploitation:** Permissionless create_pool caller sends only pool_creation_fee plus one of the required tokenfactory denom fees, satisfying .any() while skipping remaining denom creation fees.
**Insight:** When a contract re-implements fee logic for an external module (tokenfactory), diff its validation against the module's own source; .any() vs .all() and strict equality on summed amounts are common divergences.
