Part 2

Bug Description:

The receiveWethReward() function is designed to handle WETH rewards obtained by the market, distributing a portion to the protocol and another portion to vaults. If the reward comes from a previously deposited asset, the function removes that asset from the receivedFees map:

However, this blind removal of asset from receivedFees introduces two critical issues:

1. If asset does not exist in receivedFees, the remove() function from EnumerableMap will fail and revert.

   • This can occur if the function is called with an incorrect asset address, or if the asset was never added to receivedFees in the first place.

   • A revert prevents all further WETH rewards from being processed, potentially locking protocol fees permanently.

2. If an asset is partially used but not fully removed, the function incorrectly assumes it has been fully swapped.

   • Since remove(asset) does not check balances, it is possible that some amount of asset remains in the contract.

   • This can lead to accounting mismatches, where the contract believes it has removed an asset, but unaccounted funds remain in storage.

Impact:

If remove(asset) fails, the function reverts, blocking all WETH reward distribution to both vaults and the protocol. This results in unusable or locked protocol fees, harming governance, vault incentives, and the system’s overall economic stability.

Mitigation:

Instead of blindly removing asset, check if it exists before attempting removal and ensure proper tracking.