The WithdrawalPool contract processes withdrawals during the deposit function instead of in the performUpkeep function as intended. This unexpected behavior could lead to gas inefficiencies, potential front-running opportunities, and confusion for users and integrators.
The test results show that after queueing withdrawals and then calling the deposit function, all withdrawals were processed immediately:
100 withdrawals of 10 tokens each were queued, totaling 1000 tokens.
After depositing 1000 tokens, the remaining withdrawals became 0.
The checkUpkeep function returned false, indicating no upkeep was needed.
The WithdrawalPool token balance was 1000, matching the total amount of queued withdrawals.
This behavior suggests that the deposit function is processing withdrawals, which is not the expected functionality based on the contract's design.
Gas Inefficiency: Processing withdrawals in the deposit function could lead to unexpectedly high gas costs for users making deposits.
Front-running: Malicious actors could potentially front-run large deposits to benefit from immediate withdrawal processing.
Inconsistent State: The contract's state might become inconsistent with its intended design, leading to difficulties in maintenance and upgrades.
User Confusion: Users expecting withdrawals to be processed periodically might be confused by immediate processing.
Manual , Hardhat
Review and refactor the deposit function to ensure it doesn't process withdrawals.
Implement withdrawal processing exclusively in the performUpkeep function.
Add events to clearly log when and where withdrawals are being processed.
Implement additional checks in the checkUpkeep function to correctly identify when upkeep is needed.
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.