0xKann - ETH Must Be 100% Wrapped to WETH to be able to rescueToken

[sherlock-admin3]

0xKann

High

ETH Must Be 100% Wrapped to WETH to be able to rescueToken

Summary

The StreamEscrow contract relies on ERC20-compatible logic (e.g., rescueToken) for fund recovery but does not support native ETH directly. Since ETH is not an ERC20 token, attempting to manage ETH using ERC20 functions like IERC20(token).transfer() will fail.

Root Cause

The StreamEscrow contract lacks explicit handling for native ETH, relying entirely on ERC20-compatible logic. The rescueToken function assumes that all funds within the contract are in the form of ERC20 tokens (e.g., WETH), not native ETH. This means:

Native ETH cannot be transferred out using rescueToken because it is not an ERC20 token.
Any native ETH sent to the contract will remain permanently trapped since no mechanism exists to transfer it.

https://github.com/sherlock-audit/2024-11-nounsdao/blob/main/nouns-monorepo/packages/nouns-contracts/contracts/StreamEscrow.sol#L292-L294

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

Denial of Fund Recovery: If the contract inadvertently receives native ETH (e.g., via direct transfer), the funds cannot be retrieved using rescueToken, leading to loss of access to those funds.

Impact

Trapped Funds:

Native ETH sent to the contract cannot be recovered or used, resulting in a permanent loss unless additional functions are implemented to handle ETH.
Protocol Reliance on WETH:

The system must enforce a policy where all ETH is wrapped into WETH before interacting with the contract to avoid inconsistencies or operational failures.

PoC

No response

Mitigation

No response