"Burn Event Emitted Before Actual Burn Operation, Causing Potential Inconsistencies
Summary:
In the contract 'PerpetualVault.sol' in the function '_handleReturn' these lines have incorrect order
Vulnerability Details:
Currently, the function emits the Burned event before calling _burn(depositId). If _burn somehow fails, for example due to a revert in its implementation, then the event Burned would still be emitted even though the actual burn operation did not happen.
This could lead to inaccurate accounting and misleading logs, making debugging and tracking of burned deposits more difficult.
Impact:
Incorrect event logging: Off-chain systems or developers relying on logs may incorrectly assume the deposit was burned.
Harder debugging: If _burn fails, the logs will not reflect the actual contract state.
Tools Used:
Manual review
Recommendations:
To ensure correctness, swap the order:
First, execute
_burn(depositId);to guarantee that the burn operation is successful.Then emit the
Burnedevent only if the burn has actually occurred.
corrected code:
Lead Judging Commences
Informational or Gas
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Suppositions
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Informational or Gas
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Suppositions
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
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.