# Wrong Inflator used in calculating HTP to determine accrualIndex in accrueInterest

Ajna's accrueInterest computed HTP with the new inflator while LUP used old values, undercounting interestEarningDeposit and skewing lenderFactor.

- Payout: Contest reward
- Severity: medium
- Program: Ajna
- Credited: Chinmay
- Disclosed: 2023-04-20
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-ajna-judging/issues/111
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-ajna%3AM-5
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** PoolCommons.accrueInterest / Pool.sol interest accrual logic
**Root cause:** HTP is computed using newInflator_ (post-accrual debt) while LUP uses pre-accrual state, so the derived HTP index is shifted and max(LUPIndex, HTPIndex) excludes deposits between old and new HTP indices.
**Steps:**
1. Read PoolCommons.accrueInterest: accrualIndex = max(LUPIndex, HTPIndex).
2. Observe HTP computed with newInflator_ but LUP with current poolState_.inflator.
3. Assume LUP price > HTP price so LUPIndex < HTPIndex; new inflator lowers HTP index further.
4. Deposits between old HTP index and new HTP index are excluded from interestEarningDeposit.
5. interestEarningDeposit underestimated, lenderFactor at PoolCommons.sol#L253 wrong.
6. Fix: use poolState_.inflator (pre-accrual) for HTP.
**How found:** Code review of accrueInterest comparing which inflator feeds HTP vs LUP; noticed inconsistency between new and old state in the same max() computation, confirmed with developers.
**Insight:** When a function mixes pre-state and post-state variables in a single min/max selection, check each operand's snapshot timing; here the new inflator silently shifted the HTP bucket boundary.