# compute_offer_amount floors the offer_amount when simulating constant product reversed swaps, leading to unexpected results

MANTRA's compute_offer_amount floors reverse-swap output, so exact-output simulations underpay and swaps return less than the requested amount.

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

**Target:** CosmWasm pool-manager constant-product reverse swap simulation (helpers.rs)
**Root cause:** compute_offer_amount floors the Decimal256-to-Uint conversion of the offer amount, diverging from compute_swap's math and rounding down the required input.
**Steps:**
1. Create constant-product pool uluna/uusd with 100M each, zero fees.
2. Call `query_reverse_simulation` for needed_uusd=99_900_099 to get offer_uluna.
3. Swap offer_uluna uluna for uusd.
4. Observe `return_amount < needed_uusd` due to floored offer amount.
**How found:** Compared compute_offer_amount's math against compute_swap, noticed the Decimal256 to_uint_floor rounding down the offer amount, and wrote an integration test showing return_amount < needed_uusd.
**Exploitation:** Trader or integrating contract uses query_reverse_simulation to compute exact-output input; the floored result under-delivers, causing unexpected reverts or shortfall for contracts relying on exact-output flows.
**Insight:** When a protocol offers a reverse/exact-output simulation alongside exact-in swaps, diff its rounding direction against the forward swap math; a floored input guarantees the quoted output is never met.