# PositionUtils.validatePosition() uses ``isIncrease`` instead of ``false`` when calling isPositionLiquidatable(), making it not work properly for the case of ``isIncrease = true``.

GMX PositionUtils.validatePosition passes isIncrease instead of false to isPositionLiquidatable, double-counting price impact for increase orders and misjudging liquidatability.

- Payout: Contest reward
- Severity: medium
- Program: Gmx
- Credited: chaduke
- Disclosed: 2023-04-20
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-gmx-judging/issues/180
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-gmx%3AM-3
- 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:** PositionUtils.validatePosition / isPositionLiquidatable in gmx-synthetics
**Root cause:** validatePosition forwards the order's isIncrease flag into isPositionLiquidatable, but liquidation is always a decrease, so for increase orders the price impact of the increase is applied twice.
**Steps:**
1. Deploy gmx-synthetics locally with forge; comment out oracle signature/timestamp/block checks.
2. Create market, deposit collateral, execute a LimitIncrease order for depositor3.
3. Observe getPriceImpactUsd during increase: initialDiffUsd=0, nextDiffUsd=1123...e30, priceImpactUsd=-63107...e30.
4. During validatePosition, isPositionLiquidatable is called with isIncrease=true, so initialDiffUsd=1123...e30 and nextDiffUsd doubles to 2246...e30, priceImpactUsd=-189323...e30.
5. Compare against expected behavior where false is passed and only a hypothetical decrease impact is computed.
**How found:** Code reading of validatePosition's call into isPositionLiquidatable; noticed the isIncrease argument is semantically wrong since liquidation is a decrease, then confirmed double-counting of price impact via instrumented POC logs.
**Insight:** When a validation helper reuses the caller's direction flag for a hypothetical liquidation check, the impact of the just-executed trade gets applied twice; audit any isIncrease/isLong parameter passed into liquidation or decrease-path math.