# `rewardData.releaseRate` is incorrectly calculated on `RewardsController::config()` when `block.timestamp > start` and `rewardData.lastConfig != rewardData.start`

RewardsController.config() miscalculates releaseRate when start was set in the future, overestimating released rewards and underpaying users.

- Payout: Contest reward
- Severity: medium
- Program: Interest Rate Model
- Credited: 0x73696d616f
- Disclosed: 2024-04-06
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-04-interest-rate-model-judging/issues/245
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-04-interest-rate-model%3AM-16
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:precision-loss vuln:reward-distribution

**Target:** RewardsController.config() reward rate accounting
**Root cause:** Released rewards computed as releaseRate * (block.timestamp - lastConfig) instead of from start, overestimating released when start was in the future, lowering the new releaseRate.
**Steps:**
1. Initial config sets rewardData.start in the future.
2. Later call config() with block.timestamp > start, entering else branch.
3. released = lastConfigReleased + releaseRate * (block.timestamp - lastConfig) overcounts elapsed time.
4. New releaseRate = (totalDistribution - released)/(distributionPeriod - elapsed) is too low.
5. Users receive fewer rewards than intended.
**How found:** Code reading of config() else-branch math, noticing released uses lastConfig instead of start when start was future-dated.
**Insight:** When auditing reward-rate accounting, check that elapsed-time bases (start vs lastConfig) match the period the rate was meant to cover; future-dated starts break pro-rata math.