The deposit and withdraw functions in PerpetualVault lack rate limiting or throttling, allowing malicious users to repeatedly call these functions with minimal amounts. This could consume excessive gas, exhaust the vault’s ETH balance for execution fees, or overwhelm the keeper, potentially causing a denial-of-service (DoS) attack or operational delays.
The deposit and withdraw functions do not include rate-limiting mechanisms:
solidity
A malicious user could spam these functions with small amounts, consuming gas and potentially depleting the vault’s ETH balance needed for execution fees (e.g., via _payExecutionFee). This could also overload the keeper, delaying legitimate transactions.
DoS Risk: Frequent calls could exhaust the vault’s ETH balance or keeper resources, stalling operations and preventing legitimate users from depositing or withdrawing.
Increased Costs: Operational costs rise due to gas consumption, potentially impacting the vault’s profitability or sustainability.
User Frustration: Delays or failures in processing legitimate transactions could frustrate users and harm the protocol’s reputation.
Manual code review
Add rate limiting or a cooldown period for deposit and withdraw using a mapping to track the last transaction timestamp per user
Allow the owner to adjust transactionCooldown with appropriate limits:
solidity
Test the rate-limiting implementation with spam attack simulations to ensure robustness.
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.
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.
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.
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.
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.