An ERC20 that declares 18 decimals should mint amounts scaled to those decimals, consistent with how its price is expressed.
Snow inherits ERC20 without overriding decimals() (so 18), but buySnow/earnSnow mint amount raw while the price is scaled by 1e18. buySnow(1) charges the full price for 0.000000000000000001 SNOW.
Likelihood:
Every purchase and every earnSnow mints raw units, so the mismatch happens on every interaction with the token.
Impact:
The effective price is absurd (full fee per 1 wei of token) and buying a whole token would cost 1e18 times the fee.
Wallets, explorers and DEXs format via decimals(), so a legitimate holder shows 0.000000000000000001 SNOW; any integration using 1e18 breaks. Merkle allocations are built from these raw amounts.
The test asserts decimals() == 18, yet after buySnow(1) Alice's balance is 1 (i.e. 1 wei of token) - the full fee bought 0.000000000000000001 SNOW.
Verified with Foundry (test_sePagaElPrecioEnteroPorUnWeiDeToken), forge test passing:
Pick one convention and apply it consistently - either make the token indivisible, or keep 18 decimals and scale the mint:
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.