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.