buySnow() is designed to accept either native ETH or WETH. The implementation checks for an exact ETH match and falls to WETH otherwise:
Likelihood:
Any user who sends ETH with a tiny rounding error (common in frontend integrations, scripts, or manual transactions) triggers this silently.
The condition requires only that msg.value > 0 and msg.value != s_buyFee * amount, which is extremely easy to satisfy accidentally.
Since s_buyFee is scaled by 1e18, any off-by-one in the frontend fee calculation causes this.
Impact:
The user loses all sent ETH (no refund) and is also charged the full WETH amount — effectively double-paying.
If the user doesn't have sufficient WETH approved, the transaction reverts after the ETH is already deducted from their balance (ETH loss with no tokens received — but ETH is not actually taken until after the revert... wait, ETH IS sent with the tx so it stays in contract regardless of revert behavior. On revert ETH IS returned. But if safeTransferFrom succeeds, both are taken.)
At 5 ETH per token, a user attempting to buy 10 tokens could lose 50 ETH to the contract while also having 50 ETH in WETH pulled — a 100 ETH double-charge scenario.
Separate ETH and WETH paths explicitly. Require exact ETH for the ETH path and zero ETH for the WETH path, and refund any surplus ETH:
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.