The GmxProxy
contract calculates the execution fee required for order processing using tx.gasprice
, but it does so without a safety margin or validation against network conditions, potentially leading to underfunded transactions that fail to execute. Specifically, in both createOrder() and settle(), the execution fee is determined as follows:
Since tx.gasprice
fluctuates based on network congestion, the estimated fee might be too low at the time of order execution, causing GMX to reject the transaction due to insufficient gas fees. This results in stuck orders, requiring manual intervention to cancel and resubmit them, leading to execution delays and potential missed trading opportunities for the perpetual vault.
Order execution failures due to underestimated gas fees, causing stuck orders and potential loss of trading opportunities.
Implement a buffer margin (e.g. gasMultiplier
) when calculating the execution fee to account for fluctuations in gas prices, ensuring the contract always reserves sufficient ETH for execution.
The frontrunner won’t trigger "congestion" without a huge amount of transactions, and it will cost a lot. Moreover, the execution gas limit is overestimated to prevent such cases: ``` executionGasLimit = baseGasLimit + ((estimatedGasLimit + _callbackGasLimit) * multiplierFactor) / PRECISION; ``` The keeper won’t wait long to execute the order; otherwise, GMX would not be competitive.
The frontrunner won’t trigger "congestion" without a huge amount of transactions, and it will cost a lot. Moreover, the execution gas limit is overestimated to prevent such cases: ``` executionGasLimit = baseGasLimit + ((estimatedGasLimit + _callbackGasLimit) * multiplierFactor) / PRECISION; ``` The keeper won’t wait long to execute the order; otherwise, GMX would not be competitive.
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.