# Potential accounting problems due to issue in `ClearingHouse.updatePositions()`

ClearingHouse.settleFunding skips updating lastFundingTime when the last whitelisted AMM's nextFundingTime is in the future, so updatePositions skips funding settlement and PnL realization.

- Payout: Contest reward
- Severity: medium
- Program: Hubble Exchange
- Credited: lemonmon
- Disclosed: 2023-04-16
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-hubble-exchange-judging/issues/248
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-hubble-exchange%3AM-13
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error

**Target:** ClearingHouse/AMM funding settlement (Solidity contracts)
**Root cause:** settleFunding only updates lastFundingTime if the last AMM in the array returns nonzero _nextFundingTime; a newly whitelisted AMM with a future nextFundingTime makes the loop's final return zero, leaving lastFundingTime stale.
**Steps:**
1. Whitelist AMMs at 16:00 with fundingPeriod 3h -> nextFundingTime=18:00.
2. At 19:00 whitelist another AMM -> its nextFundingTime=21:00 (future).
3. Call `ClearingHouse.settleFunding()`; last AMM returns 0 for _nextFundingTime, so `lastFundingTime` is not updated.
4. Call `updatePositions()` (via `_openPosition`/`liquidate`); fundingPayment is not processed and `marginAccount.realizePnL()` is skipped.
**How found:** Code reading of settleFunding's loop: noticed lastFundingTime update is gated on the last AMM's _nextFundingTime, then reasoned that whitelistAmm can add an AMM with a different (future) nextFundingTime, breaking the sponsor's assumption that all AMMs share nextFundingTime.
**Insight:** When a loop's post-condition depends on the last element's return value, check whether heterogeneous per-element state (e.g. newly added entries with different schedules) can make the last element diverge from the rest.