# accrueInterest is expected to revert when the rate is higher than the maximum allowed rate, which is possible since the utilization can be more than 1

Moonwell's accrueInterest reverts when utilization exceeds 1 (reserves > cash), pushing borrowRate past borrowRateMaxMantissa and bricking all protocol operations.

- Payout: Audit contest
- Severity: medium
- Program: Moonwell
- Found by: 0xWaitress
- Disclosed: 2023-10-04
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-07-moonwell#m-15
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-moonwell%3AM-15
- Tags: area:web3 domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:accounting-error vuln:business-logic vuln:dos

**Target:** MToken accrueInterest / JumpRateModel utilization
**Root cause:** utilizationRate = borrows/(cash+borrows-reserves) can exceed 1e18 when reserves > cash, so getBorrowRate returns a rate above borrowRateMaxMantissa and accrueInterest's require reverts.
**Steps:**
1. Configure JumpRateModel: base 1%, multiplierPerTimestamp 5% APR, jumpMultiplier 50% APR, kink 50%.
2. Depositors withdraw until reserves exceed cash, making utilization > 1 (e.g. 101%).
3. Call any function invoking `accrueInterest()`; `getBorrowRate` returns ~29% APR > max.
4. `require(borrowRateMantissa <= borrowRateMaxMantissa, "borrow rate is absurdly high")` reverts, blocking deposit/withdraw/borrow/repay.
**How found:** Code review of accrueInterest's max-rate require against the utilization formula; noticed the comment claims utilization in [0,1e18] but reserves>cash breaks that bound.
**Insight:** When a rate model assumes utilization ≤ 1e18, check whether reserves can exceed cash (e.g. after withdrawals) to push the denominator below borrows and overflow the assumed bound.

