Loss of execution fee refund during gmx withdrawal
A bug in the afterOrderExecution function prevents users from receiving execution fee refunds when exiting GMX positions with leverage greater than one. This issue occurs because the refundFee parameter is incorrectly set to false, causing the refund process to fail.
The problem arises in the afterOrderExecution function when handling MarketDecrease orders during withdrawals. The function incorrectly sets refundFee to false in the encoded nextAction.data. This prevents the refund from being processed in the _handleReturn function. Here's how it happens:
A user calls withdraw and pays the execution fee upfront.
The Keeper executes runNextAction with WITHDRAW_ACTION, creating a GMX order to reduce the position size if it's open.
The afterOrderExecution callback is triggered with MarketDecrease, but sets refundFee to false in nextAction.data.
The Keeper runs FINALIZE with the incorrect refundFee value, resulting in no refund for the user.
Users lose their execution fee refunds when withdrawing from positions with leverage greater than one. The _payExecutionFee function allows users to send extra funds without restrictions, but these fees get stuck in the GmxProxy contract instead of being refunded. This issue is severe and directly affects user funds.
Manual Review
Modify the afterOrderExecution function to set refundFee to true when encoding nextAction.data during MarketDecrease orders in withdrawal flow. This ensures the refund is processed correctly.
According the sponsor, here is the design choice: - when there's gmx interaction, no refund. - when there's no gmx interaction, refund fee. The remaining fees are used for gas cost of the keepers.
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.