Normal behaviour: Calling burnFaucetTokens(amountToBurn) should reduce the faucet token supply by exactly amountToBurn, without transferring any unintended extra tokens to the owner.
Problem: The function first transfers the entire contract balance to the owner, then burns only the amountToBurn from the owner. This leaves the owner with the remainder (contractBalance - amountToBurn) as a windfall and does not burn the intended full faucet balance.
Likelihood:
Occurs whenever the owner invokes burnFaucetTokens during routine supply management (top-ups/deflation).
Triggers in normal operations where the owner intends to burn some portion of faucet-held tokens.
Impact:
The owner unintentionally (or intentionally) accrues the remainder of the faucet’s entire token balance.
Faucet tokenomics and supply controls are broken; the faucet may run out of tokens unexpectedly or become centralised.
Explanation: This test deploys the faucet (which mints all tokens to the contract), then calls burnFaucetTokens(100e18). Because the implementation transfers the entire faucet balance to the owner before burning, the faucet ends up with 0 tokens, and the owner keeps the remainder after burning 100e18. The assertions prove the faucet’s balance is emptied and the owner’s balance increases by more than intended.
Explanation: Burning directly from the contract’s own balance removes exactly amountToBurn tokens without transferring any excess to the owner, preserving faucet reserves and intended tokenomics. If you must burn from the owner, transfer only amountToBurn to the owner then burn that exact amount—never transfer the full faucet balance.
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.
The contest is complete and the rewards are being distributed.