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.