# WithdrawPeriphery#_convertToToken slippage control is broken for any token other than USDC

WithdrawPeriphery computed minTokenOut in 6 decimals regardless of token, so slippage protection was ineffective for 18-decimal tokens like WETH/WBTC on GMX redeems.

- Payout: Contest reward
- Severity: medium
- Program: Rage Trade
- Credited: clems4ever
- Disclosed: 2022-10-28
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-rage-trade-judging/issues/55
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-rage-trade%3AM-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:accounting-error vuln:oracle-manipulation

**Target:** WithdrawPeriphery._convertToToken / GMX rewardRouter unstakeAndRedeemGlp
**Root cause:** minTokenOut is computed via mulDiv of oracle prices and assumed to be 6 decimals, but GMX token prices/outputs for non-USDC tokens use their native decimals (e.g. 18), making the threshold orders of magnitude too small.
**Steps:**
1. Call WithdrawPeriphery redeem path with token=WETH (18 decimals)
2. Observe `minTokenOut = outputGlp.mulDiv(glpPrice*(MAX_BPS-slippageThreshold), tokenPrice*MAX_BPS)` yields a 6-decimal value
3. Passed to `rewardRouter.unstakeAndRedeemGlp(token, outputGlp, minTokenOut, receiver)` as minOut
4. Threshold is ~1e12x too small for 18-decimal token, so effectively no slippage protection
**How found:** Code review of the slippage math in _convertToToken; noticed minTokenOut is decimal-agnostic while token decimals vary.
**Exploitation:** Not directly exploitable per judge: GMX prices via Chainlink oracles with min/max spread and fees, so sandwiching is not feasible; impact is loss of slippage protection rather than active theft.
**Insight:** When a contract computes a min-out threshold from oracle prices, verify the assumed decimals match the output token's decimals—price ratios inherit the token's decimals, not the quote asset's.