The protocol uses counter
mechanism as an ID for new orders. In some cases, the PerpetualVault
contract uses counter
as the ID for deposit orders to retrieve the latest order. However, in certain places, this approach is incorrect, and only the specific depositId
should be used. Otherwise, data from the latest order will be used instead of the one currently being processed.
Let's take a look at the _handleReturn
function:
As we can see, in the refunding logic, counter
is used as the ID for depositInfo
. However, withdrawals can be made for previously created deposits, while counter
only refers to the latest one. This creates a problem: even if a user has provided sufficient gas fees and is eligible for a refund, they may not receive it. This is because the latest order might have used less gas, causing the refund calculation to underflow and the try/catch
block to skip execution.
Users may be unable to receive gas refunds in some cases or may receive an incorrect refund amount.
Manual review.
Use depositId
, as it is done in other parts of the code.
Likelihood: Medium/High, when withdraw on a 1x vault. Impact: High, the fees will be distributed to the last depositor and not the withdrawer.
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.