# Due to excessive HTP check moveQuoteToken can be unavailable for big deposits

Ajna's moveQuoteToken reverts when intermediate LUP after removal drops below HTP, blocking legitimate large deposit moves and risking depositor losses.

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

**Target:** Ajna Pool contract moveQuoteToken / LenderActions
**Root cause:** LUP is computed after removing the deposit but before adding it to the destination bucket, so the HTP > LUP check uses an intermediate state rather than the final state.
**Steps:**
1. Call `moveQuoteToken(maxAmount_, fromIndex_, toIndex_, expiry_)` with a large `maxAmount_` and `fromIndex_ < toIndex_`.
2. `_removeMaxDeposit` removes the deposit, temporarily lowering LUP.
3. `lup_ = Deposits.getLup(deposits_, poolState_.debt)` is computed on this intermediate state.
4. If `vars.htp > lup_` the check `if (params_.fromIndex < params_.toIndex && vars.htp > lup_) revert LUPBelowHTP();` reverts, even though adding the amount to `toIndex_` would restore LUP.
**How found:** Code reading of moveQuoteToken: noticed LUP is calculated between removal and addition, making the HTP check evaluate an intermediate state rather than the final pool state.
**Insight:** When a function performs remove-then-add, check invariants against the final state, not an intermediate one; recompute derived values like LUP after all balance mutations.