# Vault_Base_ERC20#_updateVirtualPrice calculates interest incorrectly if updated frequently

Isomorph Vault_Base_ERC20 truncates interest intervals but stores untruncated timestamp, letting frequent updates permanently drop accrued interest and halve borrower interest.

- Payout: Contest reward
- Severity: medium
- Program: Isomorph
- Credited: Jeiwan
- Disclosed: 2022-11-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-isomorph-judging/issues/158
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-isomorph%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Vault_Base_ERC20._updateVirtualPrice / CollateralBook virtual price
**Root cause:** threeMinuteDelta is floored via integer division, but lastUpdateTime is set to the untruncated _currentBlockTime, discarding the remainder seconds of interest each call.
**Steps:**
1. Set lastUpdateTime=1000, call at block.timestamp=1359
2. timeDelta=359, threeMinuteDelta=359/180=1, apply one interest increment
3. vaultUpdateVirtualPriceAndTime stores lastUpdateTime=1359, losing 179s of interest
4. Repeat calls just under 180s apart to continuously discard remainder interest
**How found:** Code reading of _updateVirtualPrice: noticed threeMinuteDelta floors the delta but the stored timestamp uses the raw _currentBlockTime, creating a mismatch between interest applied and time advanced.
**Exploitation:** Borrower with large debt calls the update function (or a bot does) at intervals just under 180s so each call truncates away up to 179s of interest, effectively halving accumulated interest; cheap on Optimism.
**Insight:** When an accumulator floors a time delta into discrete steps, verify the stored last-update timestamp is also floored to the same boundary; otherwise each call silently discards the remainder and frequent callers can suppress accrual.