Liquidity Management
Gamma
DeFiFoundry
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Potential loss of user's execution fee in deposit function when position is closed

incogknito

Summary

In the PerpetualVault.sol contract, when a user deposits funds while the position is closed, any ETH sent as an execution fee will be permanently stuck in the contract. This happens because the deposit function is marked as payable but fails to handle or refund the execution fee in this specific scenario.

Vulnerability Details

Looking at the deposit function when positionIsClosed is true:

function deposit(uint256 amount) external nonReentrant payable {
// ... input validation checks ...
flow = FLOW.DEPOSIT;
collateralToken.safeTransferFrom(msg.sender, address(this), amount);
counter++;
depositInfo[counter] = DepositInfo(amount, 0, msg.sender, 0, block.timestamp, address(0));
totalDepositAmount += amount;
EnumerableSet.add(userDeposits[msg.sender], counter);
​
if (positionIsClosed) {
MarketPrices memory prices;
_mint(counter, amount, false, prices);
_finalize(hex'');
} else {
_payExecutionFee(counter, true);
// ... rest of the function
}
}

The issue arises because the function is payable and can receive ETH as execution fee and when positionIsClosed is true:

  • msg.value (execution fee) is not stored in depositInfo

  • _payExecutionFee is not called

  • _mint is called with refundFee = false

  • No other mechanism exists to handle or refund the ETH

Impact

Users who send ETH as execution fee during deposit when position is closed will permanently lose their ETH. The ETH will be stuck in the contract with no mechanism to recover it. This could particularly impact users interacting through frontends that automatically include execution fees.

Tools Used

  • Manual code review

Recommendations

Add a check to prevent ETH being sent when position is closed:

function deposit(uint256 amount) external nonReentrant payable {
if (positionIsClosed && msg.value > 0) {
revert Error.InvalidExecutionFee();
}
// ... rest of the function
}
Updates

Lead Judging Commences

n0kto Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Users mistake, only impacting themselves.

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.

n0kto Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Users mistake, only impacting themselves.

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.