The refillSepEth function allows the contract owner to send ETH to the faucet contract and emits a SepEthRefilled event. While the function is marked as payable and the ETH is indeed transferred to the contract balance, it lacks any internal state updates to track the refilled amount. This makes it impossible to accurately determine how much ETH has been added to the faucet over time, relying solely on the emitted event logs.
This omission can lead to inconsistencies or confusion when assessing available ETH for dripping, monitoring refills, or auditing contract activity. Additionally, if future logic depends on the total amount of refilled ETH (for example, pausing or limiting drips based on total refills), this design could cause incorrect behavior.
Low
Logical / Transparency Issue
No internal tracking of refilled ETH, making it impossible to verify total refills from on-chain state.
Inaccurate or misleading monitoring of faucet balance and refill history.
Potential future inconsistencies if other logic relies on total refilled ETH data.
Manual Review
Implement internal accounting to track total ETH refilled into the faucet for transparency and future logic consistency:
When calling refillSepEth() with msg.value = 1 ether, the contract balance increases by 1 ETH, but no internal variable records the event, resulting in no on-chain state change beyond the emitted event. Auditors or monitoring systems relying solely on storage cannot determine cumulative refills.
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.