# `Reserves` should not be considered part of the available liquidity while calculating the interest rate

Sentiment's DefaultRateModel counted reserves as available liquidity, understating utilization and making borrow interest rates ~15% lower than documented.

- Payout: Contest reward
- Severity: medium
- Program: Sentiment
- Credited: WATCHPUG
- Disclosed: 2022-08-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-08-sentiment-judging/tree/main/266-M
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-08-sentiment%3AM-14
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:accounting-error

**Target:** LToken.getRateFactor / DefaultRateModel.getBorrowRatePerSecond (Solidity lending protocol)
**Root cause:** getRateFactor passes asset.balanceOf(address(this)) as liquidity to the rate model, but the documented utilization formula requires liquidity minus reserves; reserves are thus double-counted as lendable liquidity.
**Steps:**
1. Read docs: util = borrows / (liquidity - reserves + borrows)
2. Inspect LToken.getRateFactor: passes asset.balanceOf(address(this)) directly as liquidity
3. Inspect DefaultRateModel._utilization: totalAssets = liquidity + borrows, no reserve subtraction
4. Set balance=3000, borrows=7000, reserves=1500: actual util=0.7, rate=7763863430
5. Expected util=7000/8500=0.82, rate=9114134329; actual is 85% of expected
**How found:** Compared documented interest-rate formula against on-chain implementation; noticed getRateFactor forwards raw token balance without subtracting reserves, contradicting the docs' util definition.
**Insight:** When a protocol publishes a rate/utilization formula, diff it line-by-line against the contract: reserve or fee buckets excluded in docs are often still included in code, silently mispricing interest.