# Collateral tokens that cannot be automatically swapped to the PnL token, cannot have slippage applied to them

GMX decrease-position orders that fall back to secondary collateral token on failed swap bypass minOutputAmount slippage, forcing users to eat price impact.

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

**Target:** gmx-synthetics DecreasePositionCollateralUtils / DecreaseOrderUtils
**Root cause:** When SwapCollateralTokenToPnlToken swap reverts, collateral is returned as secondaryOutputAmount, but the single minOutputAmount slippage arg is denominated in the PnL token, so no slippage check applies to the secondary token.
**Steps:**
1. Open a decrease order with Order.DecreasePositionSwapType.SwapCollateralTokenToPnlToken and a minOutputAmount in PnL-token units.
2. Cause swapHandler.swap to revert (e.g. token paused); catch block emits SwapReverted and leaves values.output.secondaryOutputAmount set.
3. Observe DecreaseOrderUtils sends secondaryOutputAmount separately with no slippage check against minOutputAmount.
4. User receives collateral token at unfavorable price impact despite valid minOutputAmount.
**How found:** Code review of the try/catch in swapWithdrawnCollateralToPnlToken: noticed secondaryOutputAmount is only zeroed on success, and that the single minOutputAmount is denominated in the PnL token, so the fallback path has no slippage bound.
**Insight:** When a swap has a try/catch fallback path, check whether the fallback output is still covered by the same slippage parameter; a single minOutputAmount denominated in one token cannot bound a differently-denominated fallback.