# `updateState()` should be called in `depositEth()` and `redeemEth()`

LEther depositEth/redeemEth skip updateState(), so utilization changes without settling accrued interest, causing borrowers to overpay or lenders to lose yield.

- Payout: Contest reward
- Severity: high
- Program: Sentiment
- Credited: Lambda
- Disclosed: 2022-08-30
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-08-sentiment-judging/tree/main/085-H
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-08-sentiment%3AH-6
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** LEther.sol depositEth/redeemEth on LToken interest accrual
**Root cause:** depositEth() and redeemEth() change the asset balance (and thus utilization) without calling updateState()/beforeDeposit/beforeWithdraw, so pending interest is computed later using the new utilization rate over the entire elapsed period.
**Steps:**
1. Alice deposits 1000 ETH via depositEth(); Bob borrows 500 ETH (updateState called, util=0.5).
2. Wait one year with no interaction on the asset.
3. Alice calls redeemEth(500) — no updateState, util now 1.0.
4. Bob calls repay() which triggers updateState() and computes interest using util=1.0 over the full year.
5. Observe Bob pays ~1375 instead of ~587 (2x); reverse case with depositEth before repay underpays lenders.
**How found:** Code review of LToken interest accounting: noticed updateState() is invoked on borrow/repay but not on the ETH-specific deposit/redeem paths, and that getBorrowRatePerSecond depends on current liquidity, so a stale lastUpdated applies the new utilization retroactively.
**Exploitation:** No direct theft; a borrower or LP can time repay/deposit/redeem around a stale lastUpdated to shift interest owed — borrower repays after a redeem to overpay, or LP deposits before repay to dilute accrued interest, transferring value between borrowers and lenders.
**Insight:** When an interest/rate model reads live balances (utilization) but accrual is timestamp-based, any balance-mutating entrypoint that skips the accrue-first hook retroactively reprices the whole elapsed window — audit every path that moves the underlying, including ETH/wrapper variants, not just the canonical deposit/withdraw.