In the constructor, _buyFee is multiplied by PRECISION, contract deployers may simply pass the scaled value to _buyFee, e.g. _buyFee = 5 to represent 5 * (10 ^ PRECISION). This could lead to users thinking that s.buyFee is an additional cost on top of the amount that they intend to pay in ETH and SNOW tokens to mint.
There are two problems here:
The amount argument in buySnow() must be scaled by the caller, does not follow the assumption as the _buyFee argument in the constructor.
The total amount of ETH or WETH to be transferred is a product of s_buyFee and amount, instead of the sum.
The users will pay significantly higher amount in fees than the actual amount SNOW tokens to mint.
We need a better definition for buying fees. It can either be:
A percentage (or basis point) of the buy amount. OR,
A fixed amount to add on top of the buy amount. (e.g. totalAmount = s.buyFee + amount
If approach 2 is favored, then it is safe to scale _buyFee in the constructor argument.
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.