# Loss of mint rewards due to rounding in TroveManager

TroveManager downscales minted debt by VOLUME_MULTIPLIER=1e20 into uint32, so mints under 100 USBD round to zero and earn no mint rewards.

- Payout: Contest reward
- Severity: high
- Program: Bima
- Credited: santipu
- Disclosed: 2025-02-05
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_bima_december2024.pdf#3.1.5
- Library page: https://bugbountylibrary.com/r/cantina%3Abima_december2024%3A3.1.5
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:high tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss vuln:reward-distribution

**Target:** TroveManager.sol _updateMintVolume reward accounting
**Root cause:** initialAmount is divided by VOLUME_MULTIPLIER (1e20) before SafeCast to uint32, truncating any mint below 100 USBD to zero and collapsing 100-199 USBD into the same bucket.
**Steps:**
1. Open Trove minting 200 USBD (Bob) -> totalMints increments by 2
2. Open Trove minting 90 USBD (Alice) -> 90e18/1e20 = 0, no increment
3. Alice adjusts Trove twice more for 90 USBD each -> still 0 each time
4. At week end, distribute mint rewards: Bob gets all, Alice gets none despite minting 270 USBD total
**How found:** Code review of _updateMintVolume noticed the SafeCast.toUint32(initialAmount / VOLUME_MULTIPLIER) downscale and reasoned about truncation for amounts below the 1e20 multiplier.
**Exploitation:** Not an attack per se; any user minting <100 USBD per call silently accrues zero reward volume, and 100-199 USBD mints are indistinguishable, misallocating reward distribution.
**Insight:** When a protocol downscales token amounts to fit a smaller integer type for accounting, check the multiplier against realistic user amounts: any per-call amount below the multiplier truncates to zero, silently excluding small actors from reward or volume tracking.