Closed sherlock-admin2 closed 9 months ago
1 comment(s) were left on this issue during the judging contest.
takarez commented:
invalid because { in Q & A it says " Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?No"}
@jeffywu Seems the above comments does apply and this could possibly be invalid. Was this an expected decision, I'm guessing its not because you confirmed the issue?
I think this is a valid medium, perhaps I should have answered the Q&A more properly since we should adhere to ERC4626, it is literally in the name of the contract.
Escalate
This should be invalid due to below reasoning.
The contest readme mentions,
Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of? No
Most of the watsons considered the compliance of EIP4626 as non-issue/ Therefore, this common EIP4626 issue is missed by watsons. Further, sherlock rules further states,
Hierarchy of truth: Contest README > Sherlock rules for valid issues > protocol documentation (including code comments) > protocol answers on the contest public Discord channel.
So, i think Contest README is supreme for the validation of this issue. It should be noted that, the intension of sponsor being vaults should be in compliance with EIP4626 comes after end of contest.
While, i agree the sponsors should look into fixing the issue but considering sherlock rules for contest, this should be invalid.
Feel free to correct, if i am wrong.
Escalate
This should be invalid due to below reasoning.
The contest readme mentions,
Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of? No
Most of the watsons considered the compliance of EIP4626 as non-issue/ Therefore, this common EIP4626 issue is missed by watsons. Further, sherlock rules further states,
Hierarchy of truth: Contest README > Sherlock rules for valid issues > protocol documentation (including code comments) > protocol answers on the contest public Discord channel.
So, i think Contest README is supreme for the validation of this issue. It should be noted that, the intension of sponsor being vaults should be in compliance with EIP4626 comes after end of contest.
While, i agree the sponsors should look into fixing the issue but considering sherlock rules for contest, this should be invalid.
Feel free to correct, if i am wrong.
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
@jeffywu @Czar102 This issue reminds me of this, where there is a clear disparity between contest details and protocols intended logic. The severity will have to depend on its impact, but seems to me there is no direct impact on the protocol itself. However, notional values external integration of their ERC4626 vaults so unsure about validity.
https://github.com/sherlock-audit/2023-10-looksrare-judging/issues/136
I'm not sure that the impact is very large here, this vault does not actually perform the lending action itself, the "source of truth" so to speak on that is the Notional V3 protocol itself -- that determines if the lending action had sufficient funds or not. The preview methods here are largely informative.
If the rounding in previewMint is off by one then the lending would not complete successfully.
If the rounding in previewWithdraw is off by one then the contract would revert because the user does not have sufficient shares.
@jeffywu Does this mean as long as user has +- 1 share that he can then execute those functionalities as intended? If so I agree this could be low severity since the temporary DoS can be easily rectified, albeit not a desired scenario.
@nevillehuang, I spent some time on this issue and I think this is a low severity issue. What is affected here is the rounding on the previewMethods (view methods), not the actual mints and withdraws themselves.
I believe the ERC4626 recommendation may presume a vault that directly mints shares as wrappers around assets deposited, but that is not actually the case here with the fCash wrapper. The assets are sold on the Notional fCash DEX to purchase shares (no matter which method is pursued - mint or deposit). The shares purchased (fCash) strictly determines how many shares the account is minted. "Rounding" this number away from what the Notional contract returns as the valid amount of fCash would not be correct and may cause reverts when attempting to withdraw by increase the shares above the account's balance.
Ultimately, I don't think anyone integrates into ERC4626 blindly and certainly this ERC4626 contract does have its own quirks, I'm not sure what expectations around rounding would actually affect the nature of the integration. After trying a few things, I've determined that there is not actually anything to fix here.
Planning to accept escalation and invalidate issue.
Result: Invalid Unique
bitsurfer
medium
Rounding issue on
previewMint
andpreviewWithdraw
Summary
Rounding issue on
previewMint
andpreviewWithdraw
which doesn't follow EIP 4626's Security Considerations.Vulnerability Detail
Per EIP 4626's Security Considerations (https://eips.ethereum.org/EIPS/eip-4626)
Thus, the result of the
previewMint
andpreviewWithdraw
should be rounded up.ERC4626 expects the result returned from
previewWithdraw
function to be rounded up. However, within thepreviewWithdraw
function, it calls theconvertToShares
function. Meanwhile, theconvertToShares
function returned a rounded down value, thuspreviewWithdraw
will return a rounded down value instead of round up value. Thus, this function does not behave as expected.The same case goes to
previewMint
.Impact
Other protocols that integrate with wfCash might wrongly assume that the functions handle rounding as per ERC4626 expectation. Thus, it might cause some intergration problem in the future that can lead to wide range of issues for both parties.
Code Snippet
https://github.com/sherlock-audit/2023-12-notional-update-5/blob/main/wrapped-fcash/contracts/wfCashERC4626.sol#L46-L55
Tool used
Manual Review
Recommendation
Ensure that the rounding of vault's functions behave as expected.