Burns shares from owner and sends exactly assets of underlying tokens to receiver.
The withdraw function of ERC4626 should send the exact same amount of assets according to the ERC4626. However, the fCash contract would send fewer assets to the receiver. This may lead to a loss of user funds on other protocols. In certain cases, it may cause an exploit if leads to an underflow.
Here's a possible adoption scenario:
A yield aggregator with default vault set to wfcash with the following deposit function.
A better solution is to make some modifications to the notional protocol to support this functionality.
If that's not doable, there's a more common solution. The vault should withdraw slightly more fcash and
deposit back to the notional protocol.
Both withdraw and deposit functions do not conform to EIP-4626 which may lead to a loss of funds.
Further, there are several small nuances of EIP-4626 that make wfcash not compatible to ERC4626. (Will submit a QA report later)
Little nuances matter. Take, USDT, for example. A lot of gas was wasted in order to support USDT in DEFI protocols.
I admire the team that want to make wfcash as good as possible, however, a wrapped token is different to a vault token.
It's difficult to achieve two things at the same time IMHO. I recommend the team to re-consider whether to make
wfcash 4626 compatible.
Lines of code
https://github.com/code-423n4/2022-06-notional-coop/blob/main/notional-wrapped-fcash/contracts/wfCashERC4626.sol#L186-L191
Vulnerability details
Impact
The
withdraw
of wfCashERC4626 is not 4626 compatible. wfCashERC4626.sol#L186-L191According to EIP4626
The
withdraw
function of ERC4626 should send the exact same amount of assets according to the ERC4626. However, the fCash contract would send fewer assets to the receiver. This may lead to a loss of user funds on other protocols. In certain cases, it may cause an exploit if leads to an underflow.Here's a possible adoption scenario:
A yield aggregator with default vault set to wfcash with the following deposit function.
In the above scenario, the yield aggregator vault can not withdraw funds.
Proof of Concept
Recommended Mitigation Steps
A better solution is to make some modifications to the notional protocol to support this functionality. If that's not doable, there's a more common solution. The vault should withdraw slightly more fcash and deposit back to the notional protocol.
Both
withdraw
anddeposit
functions do not conform to EIP-4626 which may lead to a loss of funds.Further, there are several small nuances of EIP-4626 that make wfcash not compatible to ERC4626. (Will submit a QA report later) Little nuances matter. Take, USDT, for example. A lot of gas was wasted in order to support USDT in DEFI protocols.
I admire the team that want to make wfcash as good as possible, however, a wrapped token is different to a vault token. It's difficult to achieve two things at the same time IMHO. I recommend the team to re-consider whether to make wfcash 4626 compatible.