Liquidity Management

Summary

In the _handleReturn function, the refundFee logic incorrectly uses depositInfo[counter] instead of depositInfo[depositId] to determine the recipient (owner) and amount (executionFee) for refunding excess execution fees. The counter variable, incremented globally in the deposit function, represents the latest deposit ID, not the current withdrawal’s depositId from flowData. This results in refunds being sent to the wrong user (the owner of the most recent deposit) while the correct user receives nothing, leading to a significant misallocation of funds.

Vulnerability Details

Inside PerpetualVault.sol-

Affected Function: The bug occurs in the refundFee block of the _handleReturn function

depositId is unpacked from flowData and correctly identifies the withdrawing user’s deposit. However, the refund logic uses counter, a global variable incremented in the deposit function for each new deposit.

Refund logic mistakenly accesses depositInfo[counter] instead of depositInfo[depositId] .

Due to this, refund goes to the wrong user {depositInfo[counter].owner}, while the actual withdrawing user{depositInfo[depositId].owner} never receives their due refund.

Impact

The rightful depositor loses their leftover execution fee and a different user received funds they never claimed.

Tools Used

Manual Review

Recommendations

Replace counter with depositId in the refundFee logic to ensure the correct user receives their refund.