When a user withdraws their deposit, the contract burns(_burn()
) the depositId
, deleting its associated data before attempting to process the execution fee refund. As a result, depositInfo[depositId].executionFee
no longer exists when the refund logic runs causing the refund to fail silently, and the user loses their execution fee.
In the handleReturn()
function, the contract first deletes the deposit (_burn(depositId)
) and then tries to access depositInfo[depositId] is already deleted, its values are reset to zero due to Solidity's default mapping behavior.
This results in
depositInfo[depositId].executionFee = 0
, making the refund impossible.
Th try/catch block suppresses any error, leading to a silent failure.
The user never gets back unused execution fee.
Direct financial loss for users
Manual Review
To correct this issue the refund logic should be executed before _burn(depositId)
, ensuring the contract still has access to the execution fee.
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.