The _handleReturn function in the PerpetualVault contract is responsible for processing withdrawals and refunding execution fees to users. However, there is a critical issue in the order of operations: the function calls _burn before attempting to refund the execution fee. Since _burn deletes depositInfo[depositId], the execution fee stored in depositInfo[depositId].executionFee is lost, making it impossible to refund the fee to the user. This results in financial loss for users and a broken refund mechanism.
The _handleReturn function processes withdrawals and attempts to refund the execution fee if refundFee is true. However, it calls _burn before the refund logic, which deletes depositInfo[depositId].
The _burn function deletes depositInfo[depositId], which includes the executionFee field.
As a result, the execution fee stored in depositInfo[depositId].executionFee is lost, making it impossible to refund the fee to the user. This results in financial loss for users and a broken refund mechanism.
Execution Fee Loss: When _burn is called, depositInfo[depositId] is deleted, including the executionFee field. As a result, the execution fee is permanently lost, and the refund logic cannot access it.
Broken Refund Mechanism: The refund mechanism is effectively broken because depositInfo[depositId].executionFee is no longer available when the refund logic is executed.
The impact is High, the likelihood is High, so the severity is High.
Maunal Review
To fix this issue, the order of operations in _handleReturn should be adjusted so that the execution fee is refunded before _burn is called. This ensures that depositInfo[depositId].executionFee is still accessible when the refund logic is executed.
Likelihood: High, every time a user withdraw on 1x vault with paraswap Impact: Medium, fees never claimed to GMX and refund to the owner.
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.