Root + Impact

Description

The Snow contract imports SafeERC20 and declares `using SafeERC20 for IERC20`, signaling the intent to handle all ERC20 transfers safely (reverting on failure, handling non-standard tokens that return false instead of reverting). The problem is that `collectFee` calls `i_weth.transfer(...)` directly, bypassing SafeERC20 and ignoring the boolean return value. If the WETH token returned false on failure instead of reverting, the transfer would fail silently while collectFee continues as if it succeeded.

Risk

Likelihood:

* Occurs only if the configured WETH token returns false on a failed transfer rather than reverting (non-standard ERC20 behavior).

Impact:

* A failed WETH transfer would pass silently, with collectFee reporting success while the fee is not actually collected. Inconsistent with the contract's own SafeERC20 usage elsewhere.

Proof of Concept

This is a code-quality / consistency defect rather than a directly exploitable bug with standard WETH. The issue is demonstrable by inspection: The contract declares `using SafeERC20 for IERC20;` and correctly uses safe patterns elsewhere, but collectFee bypasses it:

If i_weth were a non-standard ERC20 that returns false on failure instead of reverting (a well-known class of tokens, e.g. tokens that don't revert), the transfer would fail silently: collectFee would emit no error for the WETH portion and the fee would remain uncollected, while the function proceeds to the ETH sweep and returns successfully. SafeERC20 exists precisely to handle this case by checking the return value.

Recommended Mitigation

Use safeTransfer (already available via the `using SafeERC20 for IERC20` declaration) to be consistent with the rest of the contract and to correctly handle non-standard ERC20 tokens.