Liquidity Management

Summary

The _transferToken function in the PerpetualVault contract is susceptible to a reentrancy attack because it performs an external safeTransfer call to depositInfo[depositId].recipient before updating the contract state (e.g., totalDepositAmount -= depositInfo[depositId].amount). A malicious recipient contract could re-enter the function, repeatedly draining funds or manipulating share balances.

Vulnerability Details

• The _transferToken function uses collateralToken.safeTransfer to send tokens to depositInfo[depositId].recipient:

  solidity

  try collateralToken.safeTransfer(depositInfo[depositId].recipient, amount - fee) {} catch {

  collateralToken.safeTransfer(treasury, amount - fee);

  emit TokenTranferFailed(depositInfo[depositId].recipient, amount - fee);

  }

• State updates, such as totalDepositAmount -= depositInfo[depositId].amount, occur after the external call. If depositInfo[depositId].recipient is a malicious contract, it can re-enter _transferToken via its fallback or receive function before the state is updated, allowing multiple withdrawals of the same funds.

• This violates the checks-effects-interactions pattern, making the contract vulnerable to reentrancy attacks.

Impact

• Fund Loss: An attacker could drain the vault’s collateral, potentially depleting all funds and causing significant financial losses for users.

• Vault Insolvency: The contract could become insolvent, preventing legitimate withdrawals and disrupting operations.

• User Trust Erosion: The exploit could damage the protocol’s reputation, leading to loss of users and adoption.

Tools Used

• Manual code review

Recommendations

Implement OpenZeppelin’s ReentrancyGuard or use the checks-effects-interactions pattern by updating state before performing external calls