Raisebox Faucet

Business Logic : Minting logic and inequality flaws can leads to frequent balance revert

Description

The claimFaucetTokens has this inequality at the start of the function:

This means that even if there is sufficient balance for one more drip, the function will revert.

and the mintFaucetTokens function doesn't help because of this statement:

The balance check is set so that when the balance of the protocol is above 1000 * 10 ** 18 (= 1 faucetDrip), the owner can't mint a new token.
This means he is obligated to wait for the last drip possible before replenishing the protocol.

Risk

If the owner needs to wait until the last drip possible to be able to mint a new token, he/she will manually check the protocol tokens balance until the last drip before calling the minting function, and a lot of users can quickly call the claimFaucetTokens in a relatively small amount of time.
A revert RaiseBoxFaucet_InsufficientContractBalance(); can frequently append.

Proof of Concept

See the following scenario:

1. The balanceOf(address(this)) == 4000 * 10 ** 18.

2. The 2 users call claimFaucetTokens in a relatively small amount of time.

3. BalanceOf(address(this)) == 2000 * 10 ** 18.

4. Owner can't call the MintFaucetTokens, as if (balanceOf(address(to)) > 1000 * 10 ** 18) is not fulfilled.

5. 2 users call claimFaucetTokens, in a relatively small amount of time.

6. Revert RaiseBoxFaucet_InsufficientContractBalance() is called for last user because of this check in claimFaucetTokens.
   if (balanceOf(address(this)) <= faucetDrip)

Recommended Mitigation

The recommended mitigation can be to remove the statement in mintFaucetTokens and add strict inequality to claimFaucetTokens.