The root cause is a multiplication by PRECISION (1e18) when storing the fee in the constructor, which then gets multiplied again by the purchase amount in buySnow. This results in a required payment that is astronomically large and completely impractical, effectively breaking the purchase functionality.
Normally, a user should be able to buy tokens by paying a reasonable fee. For example, if the fee is set to 1 unit (say 1 dollar worth of ETH), buying 1 token should cost around that fee. However, because the contract multiplies the fee by PRECISION during deployment and then again by the token amount during purchase, the actual amount required becomes enormous. For a fee of 1, buying 1 full token (18 decimals) would require 1e36 wei, which is far more than all the Ether that exists. Even buying just 1 wei of the token costs 1 Ether, making the token impossible to buy in any reasonable quantity.
Likelihood:
Users cannot buy tokens in any practical amount; the purchase function is effectively unusable.
The contract’s intended functionality (buying Snow tokens) is broken, and any value sent with a purchase will be either stuck or require enormous amounts to work.
Impact:
Impact 1
Impact 2
The following Foundry test demonstrates the issue. With _buyFee = 1, buying 1 wei of Snow costs 1 Ether, and buying 1 full token would require 1e36 wei (more than total Ether supply).
The fee should not be multiplied by PRECISION in the constructor. Instead, the _buyFee should represent the actual cost per full token (in wei), and the buySnow function should multiply that base fee by the amount (in token units). Alternatively, if a fixed fee per token is desired, store it as is and do not multiply by PRECISION.
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.