The getExecutionGasLimit function in the GmxProxy contract is not handling all order types correctly when calculating gas limits. According to GMX's ExecuteOrderUtils.sol contract, all orders except liquidation and ADL (automatic deleveraging) orders should incur a gas fee based on the swap, increase, and decrease types. However, the current implementation only accounts for a subset of order types, leading to incomplete gas fee calculations and transaction failure.
The existing code in the getExecutionGasLimit function only handles gas limit calculations for MarketIncrease, MarketDecrease, and MarketSwap order types. It fails to consider all limit orders and stop orders:
Limit Orders and Stop Orders: These types of orders should also be charged gas fees, but they are not currently considered.
contracts/GmxProxy.sol:getExecutionGasLimit#L171-L191
However, all orders except liquidation and ADL (automatic deleveraging) orders should incur a gas fee based on the swap, increase, and decrease types, according to GMX's ExecuteOrderUtils.sol contract.
The incomplete handling of order types leads to erroneous gas calculations for certain orders, impacting both the accuracy of gas estimations, Keeper incentives and transaction failure.
Incomplete Gas Fee Calculation: Limit orders, stop-loss orders are not charged the correct gas fees, leading to inaccuracies in gas estimations.
This discrepancy may cause Keepers to incorrectly estimate execution costs, leading to inefficient transaction execution or even transaction failures.
Manual Code Review
It is recommended to modify the getExecutionGasLimit function to account for all necessary order types, including all limit, stop-loss. Specifically:
For Limit and Stop Orders: Add logic to treat them like market orders in terms of gas fee calculation.
For Liquidation and ADL Orders: Return a gas fee of 0 for these order types, as they are subsidized by the treasury.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
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.