# Global position-fee-related state not updated until _after_ liquidation checks are done

GMX Synthetics checks liquidation eligibility before updating funding/borrowing fee state, so positions that should be liquidatable in the current block are not, delaying liquidation and increasing losses.

- Payout: Contest reward
- Severity: medium
- Program: Gmx
- Credited: IllIllI
- Disclosed: 2022-09-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-gmx-judging/issues/158
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AM-18
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:liquidation

**Target:** DecreasePositionUtils.decreasePosition liquidation check ordering
**Root cause:** isPositionLiquidatable is evaluated using stale funding/borrowing state because updateFundingAndBorrowingState runs after the liquidation check, so fee multipliers/factors are not yet applied.
**Steps:**
1. Open a position whose liquidation threshold depends on accrued funding/borrowing fees.
2. Trigger a liquidation order in a block where updated fee state would make the position liquidatable.
3. Observe isPositionLiquidatable returns false using pre-update state and reverts with PositionShouldNotBeLiquidated.
4. Liquidation only succeeds in a later block after state updates, delaying it.
**How found:** Code reading of DecreasePositionUtils.decreasePosition ordering: noticed the liquidation check at line 162 precedes updateFundingAndBorrowingState at line 173.
**Exploitation:** Not an attacker-driven exploit; a keeper/liquidator attempting liquidation in the current block reverts, deferring liquidation to the next block and allowing larger losses to accrue.
**Insight:** In perp/DEX protocols, audit the ordering of state-update calls relative to validity/liquidation checks; stale fee or funding state at check time can make solvency gates evaluate against outdated values.