# Division before multiplication result in loss of token reward if the reward update time elapse is small

OTLM.currentRewardsPerToken divides by REWARD_PERIOD before multiplying, so frequent updates with low-decimal reward tokens round rewards to zero.

- Payout: Contest reward
- Severity: medium
- Program: Bond
- Credited: TrungOre
- Disclosed: 2023-06-26
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-bond-judging/issues/87
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-bond%3AM-7
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss

**Target:** Solidity staking/liquidity-mining contract (OTLM.sol)
**Root cause:** rewardsToApply = ((elapsed * rewardRate) / REWARD_PERIOD) performs integer division before the subsequent multiplication by 10**stakedTokenDecimals, truncating small elapsed-time rewards to zero.
**Steps:**
1. Read OTLM.currentRewardsPerToken: `rewardsToApply = ((block.timestamp - lastRewardUpdate) * rewardRate) / REWARD_PERIOD`
2. Note REWARD_PERIOD = 1 days = 86400 and division truncates
3. Set reward token with low decimals (e.g. Gemini USD, 2 decimals), rewardRate = 1000*10**2 = 100000
4. Call reward update every 8 seconds: `8 * 100000 / 86400` rounds down to 0
5. Observe rewardsPerTokenStored never increases; users accrue no rewards
**How found:** Code review of reward accrual math; noticed division precedes multiplication and reasoned that short elapsed intervals combined with low-decimal tokens truncate the numerator to zero.
**Insight:** When auditing reward-per-token accumulators, check operation ordering and test with low-decimal tokens (USDC 6, GUSD 2) and short update intervals—truncation that looks negligible at 18 decimals becomes total loss at 2.