The PerpetualVault.sol
contract maintains a totalDepositAmount
variable that tracks the total amount of ERC20 tokens deposited by users. However, inconsistencies can arise between this variable and the contract's actual token balance due to direct token transfers, potential execution failures, or logic errors in updating totalDepositAmount
. Additionally, since totalDepositAmount
cannot exceed maxDepositAmount
, the contract balance should also never be greater than maxDepositAmount
.
Proof of code
Issues
Direct ERC20 Transfers: Users can send tokens directly to the contract without using deposit, causing the contract’s balance to increase while totalDepositAmount remains unchanged.
Transfer Failures: If safeTransferFrom fails silently due to token implementation quirks, totalDepositAmount will be updated incorrectly.
Incorrect totalDepositAmount Updates: If the transfer amount is lower than expected or fails mid-execution, totalDepositAmount will not reflect the correct balance.
Exceeding maxDepositAmount: While totalDepositAmount cannot exceed maxDepositAmount, external transfers could still push the contract’s balance beyond maxDepositAmount, causing inconsistencies.
Proof of Concept (PoC)
Scenario 1: Direct Token Transfers
A user can send tokens directly to the contract, bypassing the deposit function:
This increases the contract’s balance but does not update totalDepositAmount, leading to inconsistencies and potentially exceeding maxDepositAmount.
Scenario 2: ERC20 Token with Faulty safeTransferFrom Implementation
Some ERC20 tokens may have non-standard implementations that fail silently:
manual review
Implement a Recovery Mechanism for Direct Transfers
Create a function to sync totalDepositAmount with the actual balance, ensuring it does not exceed maxDepositAmount:
Verify Transfer Success
Ensure that safeTransferFrom has executed successfully before updating totalDepositAmount:
The issue of totalDepositAmount desynchronization is critical and could lead to financial loss or exploits. Additionally, ensuring that the contract balance never exceeds maxDepositAmount prevents unintended behaviors. Implementing the recommended mitigations will improve the contract’s reliability and security, ensuring accurate tracking of deposited funds.
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.
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.
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.
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.
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.