Snowman Merkle Airdrop

Description

collectFee sends the collected WETH using a raw transfer and ignores its return value:

The native-ETH leg is checked (require(collected, ...)), but the ERC20 leg is not. i_weth is typed as a generic IERC20, and many ERC20 implementations signal failure by returning false instead of reverting (and some non-standard tokens return no value at all). A raw unchecked transfer would then silently "succeed" at the call site even though no tokens moved.

The project's canonical WETH returns true and reverts on failure, so for that exact token this is latent rather than exploitable today; but the contract takes the token address at construction and uses the unchecked pattern, which is inconsistent with the rest of the codebase (which uses SafeERC20 elsewhere) and unsafe if the configured token is ever non-standard.

Risk

Likelihood: Low — the configured WETH reverts on failure, so the unchecked return is only reachable if a non-standard / misconfigured token is used for i_weth.

Impact: Low — a silently failed transfer would make collectFee appear to succeed while leaving the fees in the contract; no third-party funds are at risk.

Impact

If i_weth is ever a token that returns false on failure (or returns no value), collectFee can report success while the WETH never actually transfers, leaving collected fees stuck and giving the collector a false confirmation.

Proof of Concept

This is a static best-practice defect. The ERC20 leg is unchecked:

while the ETH leg immediately below it is checked:

A token whose transfer returns false on failure would pass the first line without reverting, so collectFee returns successfully even though no WETH moved.

Recommended Mitigation

Use OpenZeppelin SafeERC20 for the token transfer, consistent with the rest of the contract: