Fee Refund Logic’s Dependence on Global Deposit Counter
PerpetualVault.sol
Description:
In both the minting (_mint) and withdrawal (_handleReturn) routines, any excess execution fee is refunded using the deposit record referenced by the global counter (depositInfo[counter]). The deposit flow creates a deposit record with an incremented counter, but the refund logic does not explicitly tie itself to the deposit ID that initiated the flow.
Rootcause:
Although the design enforces sequential deposits (and the current flows assume a single deposit being processed at a time), this approach is fragile. In a multi‑deposit scenario or if flows become interleaved in unexpected ways, the use of a global counter might result in a fee refund referencing the wrong deposit record. This could lead to misallocated fee refunds—either depriving a depositor of a refund they’re due or inadvertently crediting an incorrect deposit.
Recommendation:
Refactor the refund logic to always reference the specific deposit ID associated with the current operation rather than relying on the global counter. This would ensure that refunds are applied correctly, even if multiple deposits are in process.
Lead Judging Commences
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.