# Slippage is not respected if PnL swap associated with a decrease order fails

GMX decrease orders bypass slippage checks when the PnL swap fails, transferring output tokens directly so users receive less than minOutputAmount.

- 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/159
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AM-17
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** DecreaseOrderUtils._handleSwapError in gmx-synthetics
**Root cause:** When the PnL swap fails, _handleSwapError transfers result.outputAmount directly to the receiver without verifying it meets minOutputAmount, so the slippage check embedded in the swap is skipped.
**Steps:**
1. Submit a decrease order with a PnL swap and a minOutputAmount.
2. Cause the swap to fail (market disabled, swap impact too large, or intermediate token paused).
3. Observe _handleSwapError transferring result.outputAmount to order.receiver() without comparing to minOutputAmount.
**How found:** Code review of the swap error handling path in DecreaseOrderUtils, noticing the direct transferOut bypasses the slippage check that lives inside the swap.
**Exploitation:** Attacker/user triggers a decrease order whose PnL swap reverts; the fallback path pays out the raw outputAmount, which can be far below the expected minOutputAmount due to price impact, causing user fund loss.
**Insight:** Audit fallback/error-handler branches of swap flows: slippage and min-output checks often live inside the swap call, so any catch/error path that pays out directly silently skips them.