Raisebox Faucet

First Flight #50
Beginner FriendlySolidity
100 EXP
View results
Submission Details
Impact: low
Likelihood: low
Invalid

# Missing Internal Accounting in `refillSepEth` Function (Low Impact)

Description

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.

Severity

Low

Risk

Logical / Transparency Issue

Impact

  • 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.

Tools Used

Manual Review

Recommended Mitigation

Implement internal accounting to track total ETH refilled into the faucet for transparency and future logic consistency:

uint256 public totalSepEthRefilled;
event SepEthRefilled(address indexed refiller, uint256 amount);
function refillSepEth(uint256 amountToRefill) external payable onlyOwner {
require(amountToRefill > 0, "invalid eth amount");
require(msg.value == amountToRefill, "Refill amount must be same as value sent.");
totalSepEthRefilled += amountToRefill; // Track total refilled amount
emit SepEthRefilled(msg.sender, amountToRefill);
}

Proof of Concept

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.

Updates

Lead Judging Commences

inallhonesty Lead Judge 5 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.