Incorrect Refund Logic Due to Data Deletion
Summary
The refund logic in the PerpetualVault contract’s _handleReturn function executes after the deposit data is deleted, making it impossible to process refunds correctly.
Vulnerability Details
In the [PerpetualVault.sol:1143](https://github.com/CodeHawks-Contests/2025-02-gamma/blob/main/contracts/PerpetualVault.sol#L1143) _handleReturn function, the _burn(depositId) call occurs before the refund logic. This deletes the depositInfo[depositId] struct, resetting depositInfo[depositId].executionFee to 0. As a result, the refund condition depositInfo[depositId].executionFee > usedFee always evaluates to false, blocking any refund transfers.
Impact
Users cannot receive refunds for unused execution fees, resulting in financial losses for those who overpaid fees expecting a refund.
Tools Used
Manual code review and analysis.
Recommendations
Relocate the refund logic to execute before the _burn(depositId) call. This ensures that depositInfo[depositId] remains intact and contains accurate data when the refund is calculated and processed.
Lead Judging Commences
finding_burn_depositId_before_refund
Likelihood: High, every time a user withdraw on 1x vault with paraswap Impact: Medium, fees never claimed to GMX and refund to the owner.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.