The contract constructor initializes the feeAddress variable without checking the input that is being assigned to it:
the _feeAddress parameter is assigned directly to the feeAddress storage variable without validation. This means that a zero address or invalid address could be set, potentially causing fees to be lost or transferred into an unattended address, making the contract unusable.
Severity: Low
Type: Input Validation / Correctness
Impact: Assigning an invalid address could lead to operational issues, such as fees being sent to the zero address or other unintended behavior.
Probability of Occurrence: Medium
This issue can occur if a developer or deployer mistakenly passes address(0) or an unintended invalid address during deployment. Since the constructor does not enforce validation, this is moderately likely in manual deployments or test scenarios.
Operational correctness: Invalid feeAddress may break fee transfers.
Maintainability: Future developers may assume the address is always valid, introducing subtle bugs.
Best Practices: Input validation on constructor parameters improves contract reliability and robustness.
Current constructor assignment:
If _feeAddress is address(0), any fee transfers will be burnt, and therefore lost forever. For example here:
Here, the feeAddress is used as a transfer destination, therefore if feeAddress == address(0), the fees will be burnt and lost forever.
Add input validation for _feeAddress to ensure it is not the zero address.
Optionally, add similar validation for other critical constructor parameters if needed (e.g., `_entranceFee > 0`).
Maintain consistency with other initialization logic to ensure robust contract deployment.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.