The executionfee is refunded when the keeper calls cancelFlow().
In case of deposit flow, the executionFee is correctly handled by transferring the fees to the depositInfo[counter].owner since counter denotes id of the last deposit.
But in case of withdraw , using counter as depositId is incorrect since the actual depositId is stored in the flowData.
When a user calls withdraw(recipient,depositId) , the depositId is stored in the variable flowData. code
But when a keeper calls cancelFlow() later , the depositId of current processing deposit is taken from counter instead of flowData.
Similar bug can be seen in handleReturn() too.code . This get triggered when a keeper executes decreaseOrder for a 1x long swap maket by only using dexSwap.
When keeper cancels a withdraw flow , the executionFee is refunded to the wrong account(the owner of the last deposit).
Manual
use flowData instead of counter.
Likelihood: Low, contract has to call cancelFlow after a withdraw, and the settle action is already executed by GMX. Impact: High, the fees will be distributed to the last depositor and not the withdrawer.
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.