DeFiFoundry
50,000 USDC
View results
Submission Details
Severity: low
Invalid

Complete ETH Withdrawal Without Reserving orderExecutionFee

Description

The function withdrawEth in gmxProxy transfers the entire ETH balance of the contract to the owner without reserving a small amount (0.002 ETH) required for orderExecutionFee. This can lead to failed order executions in the createOrder function if the contract lacks sufficient ETH for gas fees.

function createOrder(
Order.OrderType orderType,
IGmxProxy.OrderData memory orderData
) public returns (bytes32) {
...
require(
@=> address(this).balance >= positionExecutionFee,
"insufficient eth balance"
);
function withdrawEth() external onlyOwner returns (uint256) {
uint256 balance = address(this).balance;
@=> payable(msg.sender).transfer(balance);
return balance;
}

Impact:

Potential failure of order execution due to insufficient ETH balance.
Increased risk of operational disruption.

The contract may require manual ETH top-ups to continue functioning properly.

Recommendation:

Ensure that 0.002 ETH is always reserved in the contract before withdrawing.

Suggested Fix:
Modify the function to keep 0.002 ETH in the contract:

function withdrawEth() external onlyOwner returns (uint256) {
uint256 balance = address(this).balance;
+ uint256 amountToWithdraw = balance > 0.002 ether ? balance - 0.002 ether : 0;
+ if (amountToWithdraw > 0) {
+ payable(msg.sender).transfer(amountToWithdraw);
+ }
+ return amountToWithdraw;
- payable(msg.sender).transfer(balance);
- return balance;
}

This ensures that 0.002 ETH is retained for orderExecutionFee, preventing execution failures due to insufficient funds.

Updates

Lead Judging Commences

n0kto Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Admin is trusted / Malicious keepers

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. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.