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

Unsafe Token Transfer with Insufficient State Management

0x68

Bug Report: Unsafe Token Transfer with Insufficient State Management

Summary

The _transferToken function in PerpetualVault contract has a critical reentrancy vulnerability combined with inconsistent state management that could lead to fund loss and incorrect accounting.

Vulnerability Details

function _transferToken(uint256 depositId, uint256 amount) internal {
uint256 fee;
if (amount > depositInfo[depositId].amount) {
fee = (amount - depositInfo[depositId].amount) * governanceFee / BASIS_POINTS_DIVISOR;
if (fee > 0) {
collateralToken.safeTransfer(treasury, fee); // External call #1
}
}
try collateralToken.transfer(depositInfo[depositId].recipient, amount - fee) {} // External call #2
catch {
collateralToken.transfer(treasury, amount - fee); // External call #3
emit TokenTranferFailed(depositInfo[depositId].recipient, amount - fee);
}
totalDepositAmount -= depositInfo[depositId].amount; // State change after external calls
emit GovernanceFeeCollected(address(collateralToken), fee);
}

Key issues:

  1. Multiple external calls before state changes

  2. No reentrancy guard

  3. Inconsistent use of SafeERC20 (mixes safeTransfer and transfer)

  4. State changes occur after external calls

  5. No zero-address validation for recipient

Impact

High severity - The vulnerability could lead to:

  1. Reentrancy attacks through malicious tokens

  2. Double withdrawals

  3. Incorrect deposit amount accounting

  4. Loss of funds through failed transfers

  5. Inconsistent contract state

Tools Used

  • Manual code review

  • Static analysis

Recommendations

Short-term fixes:

function _transferToken(uint256 depositId, uint256 amount) internal {
// Validate inputs
require(depositInfo[depositId].recipient != address(0), "Invalid recipient");
// Update state first
uint256 oldDepositAmount = depositInfo[depositId].amount;
totalDepositAmount -= oldDepositAmount;
// Calculate fee
uint256 fee;
if (amount > oldDepositAmount) {
fee = (amount - oldDepositAmount) * governanceFee / BASIS_POINTS_DIVISOR;
}
// Transfer fee
if (fee > 0) {
collateralToken.safeTransfer(treasury, fee);
emit GovernanceFeeCollected(address(collateralToken), fee);
}
// Transfer remaining amount
uint256 transferAmount = amount - fee;
bool success = collateralToken.safeTransfer(depositInfo[depositId].recipient, transferAmount);
if (!success) {
collateralToken.safeTransfer(treasury, transferAmount);
emit TokenTranferFailed(depositInfo[depositId].recipient, transferAmount);
}
}

Long-term fixes:

  1. Add nonReentrant modifier

  2. Use SafeERC20 consistently

  3. Add comprehensive input validation

  4. Consider implementing a withdrawal pattern

  5. Add more detailed events for better tracking

  6. Add comprehensive test coverage for edge cases

Updates

Lead Judging Commences

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

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.

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

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.

Support

FAQs

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