The Snow constructor is intended to accept a fee parameter and store it for use in buySnow(). The buySnow() function computes the required payment as s_buyFee * amount. The constructor also reverts on _buyFee == 0 (line 65), so the only value that would avoid the inflation is explicitly blocked.
The constructor multiplies _buyFee by PRECISION (1e18) before storing it in s_buyFee. Then buySnow() applies the already-scaled fee directly to the token count. This inflates the required payment by a factor of 1e18, making buySnow() permanently unusable for any realistic fee value.
Likelihood:
Every valid deployment triggers this bug — the constructor reverts on _buyFee == 0, so there is no valid constructor input that avoids the inflation
Both payment paths are affected: the ETH path checks msg.value == (s_buyFee * amount), and the WETH fallback calls safeTransferFrom with the same inflated value
Impact:
With _buyFee = 1 (intending 1-wei fee), the contract requires 1 ETH per token instead of 1 wei
With _buyFee = 1e16 (0.01 ETH intended), the stored value becomes 1e34, requiring 1e16 ETH per token — roughly 83 million times the entire ETH supply
buySnow() is the primary Snow token acquisition function — the double-scaling makes it permanently uncallable for any standard deployment
Or, if the intent is to accept integer fee values and convert them to 18-decimal form, add a compensating division in buySnow():
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.