The createOrder function does not pass the swapPath parameter (from orderData) to getExecutionGasLimit, leading to incorrect gas estimations for orders involving multi-hop swaps. This results in transactions reverting due to insufficient gas, risking failed order executions.
The getExecutionGasLimit function relies on swapPath.length to calculate the number of swaps (numSwaps = swapPath.length - 1). However, createOrder does not provide swapPath to getExecutionGasLimit, causing the latter to default to 1 swap (or zero if uninitialized).
Scenario: Multi-Hop Swap with 2 Swaps
Order Data:
swapPath = [ETH, BTC, USDC](2 swaps).
SINGLE_SWAP_GAS_LIMIT = 50,000 gas.
tx.gasprice = 20 gwei.
Current Behavior:
getExecutionGasLimit assumes numSwaps = 0 (no swapPath passed).
Gas allocated: 0 * 50,000 = 0 gas for swaps.
positionExecutionFee = (baseGas + 0) * 20 gwei = undervalued fee.
Execution:
The contract checks address(this).balance >= undervalued fee (passes).
During execution, the transaction requires 2 * 50,000 = 100,000gas but only0` gas is allocated → Revert.
Orders requiring multi-hop swaps will revert due to gas exhaustion.
Manual review
Pass swapPath to getExecutionGasLimit in createOrder:
Update getExecutionGasLimit to Use swapPath:
Likelihood: Low/Medium, when swapPath has more than 1 item. Impact: Medium/High, could lead to not enough fee collected to execute the transaction in GMX
Likelihood: Low/Medium, when swapPath has more than 1 item. Impact: Medium/High, could lead to not enough fee collected to execute the transaction in GMX
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.