Closed code423n4 closed 2 years ago
@gzeoneth I do not believe this is a duplicate of #155, although it also relates to ERC4626 compatibility. It is a separate issue regarding potential integer underflows in a separate part of the implementation.
I have commented in #155
Judging this and all duplicate regarding EIP4626 implementation as High Risk. EIP4626 is aimed to create a consistent and robust implementation patterns for Tokenized Vaults. A slight deviation from 4626 would broke composability and potentially lead to loss of fund (POC in https://github.com/code-423n4/2022-06-notional-coop-findings/issues/88 can be an example). It is counterproductive to implement EIP4626 but does not conform to it fully. Especially it does seems that most of the time
deposit
would be successful but notwithdraw
, making it even more dangerous when an immutable consumer application mistakenly used the wfcash contract.
I don't believe each of these issues (although in different part of the contract) deserves a unique High Risk finding because individually none of them lead to direct loss of fund. I think the bigger picture is that general incompatibility with EIP4626 may lead to loss of fund with integration that expected compliance with EIP4626, and that's why I consider them all as duplicates.
Alternatively I can judge each of them as a Med RIsk issue, but I would prefer to stress the High Risk nature of EIP4626 non-compliance. In terms of warden reward a High Risk with 5 duplicate should be similar to solo Med Risk.
Understood, I don't see any need to change the judging in that case.
Judge has assessed an item in Issue #104 as High risk. The relevant finding follows:
L02: Incompatibility with ERC-4626
Line References
https://github.com/code-423n4/2022-06-notional-coop/blob/6f8c325f604e2576e2fe257b6b57892ca181509a/notional-wrapped-fcash/contracts/wfCashERC4626.sol#L23
https://github.com/code-423n4/2022-06-notional-coop/blob/6f8c325f604e2576e2fe257b6b57892ca181509a/notional-wrapped-fcash/contracts/wfCashERC4626.sol#L42
https://github.com/code-423n4/2022-06-notional-coop/blob/6f8c325f604e2576e2fe257b6b57892ca181509a/notional-wrapped-fcash/contracts/wfCashERC4626.sol#L48
Description
The EIP-4626 specification requires that
totalAssets()
to NOT revert, but the current implementation does so in the underlying methods:Recommended Mitigation Steps
Consider returning 0 if the condition is not met.
As a consequence, because
totalAssets()
can now possibly return 0,convertToShares()
has to be modified to check thattotalAssets()
is non-zero instead oftotalSupply()
to ensure compatibility with the specification: “MUST NOT revert unless due to integer overflow caused by an unreasonably large input.”