No events emitted within adjustDailyClaimLimit, hindering transparency and off-chain tracking of critical parameter changes

Description

• The RaiseBoxFaucet::adjustDailyClaimLimit function allows the owner to modify the dailyClaimLimit, which controls how many users can claim tokens each day. However, the function does not emit any events — like the rest of critical state-changing functions — when the limit is adjusted, making it difficult for off-chain systems and users to track changes to this important parameter.

• With this, users will never know when the dailyClaimLimit has been changed, and by how much. Even Slither highlights this issue, and somehow considers it important: Missing events arithmetic

  function adjustDailyClaimLimit(uint256 by, bool increaseClaimLimit) public onlyOwner {

  if (increaseClaimLimit) {

  dailyClaimLimit += by;

  } else {

  if (by > dailyClaimLimit) {

  revert RaiseBoxFaucet_CurrentClaimLimitIsLessThanBy();

  }

  dailyClaimLimit -= by;

  }

  @> // No event emitted here to indicate the change in dailyClaimLimit

  }

Risk

Likelihood: Medium

• The owner may frequently adjust the dailyClaimLimit based on user demand or operational needs, making it likely that changes will go unnoticed without event logging.

Impact: Low

• Lack of event logging reduces transparency and makes it harder for users and off-chain systems to monitor changes, but does not directly affect contract functionality or security.

Proof of Concept

• We can talk about two scenarios here:

  1. Scenario_1: A user wanted to claim tokens, but somehow the dailyClaimLimit has already been reached. So the user decides to wait for the next day. However, in the meantime, the owner has increased the dailyClaimLimit to allow more users to claim tokens. But the user has no way of knowing this change, and thus, he misses out on the opportunity to claim tokens.

  2. Scenario_2: A user checks that he can still claim tokens today and decides to do so. However, as he calls the claimFaucetTokens function, it reverts because the dailyClaimLimit was already decreased by the owner, of which he had no idea.

• Both scenarios highlight the importance of event logging for critical state changes, as it helps users stay informed and make better decisions.

Recommended Mitigation

An event should be emitted whenever the dailyClaimLimit is adjusted.