EIP4626 is one of the best innovations which recently happened to the DeFi space, providing a much needed standardization in a field where every protocol had its own different way of dealing with yield strategies.
The ERC4626 standard still remains a new standard that needs more iterations and protocols using it to be as refined as the ERC20 standard today.
It would notably deserve some extensions to increase its modularity and the use cases it supports.
The ERC4626 standard works super well for "liquid" protocols (Aave, Compound, Yearn) where funds earning yield can most of the time be immediately withdrawn, but it is not fully suited for protocols where assets controlled cannot be accessed in one transaction.
This last setting is for instance that of under-collateralized lending protocols where assets tend to be fully lent to off-chain entities.
Under-collateralized lending protocols are an interesting way to get a yield on chain. Goldfinch for instance provides a >7.8% APR on its >$100m TVL. Issue so far with Goldfinch is that demand for borrowing far exceeds lending demand, and new lenders going in may face difficulties withdrawing their USDC liquidity. Even worse, whenever liquidity is freed by borrowers who are repaying their loan, some MEV bots are front-running other lenders which want to withdraw and arbitraging secondary market liquidity on the pool token (called the FIDU token in this case).
In this setting, relying on the ERC4626 standard would imply that the withdraw and redeem, previewRedeem and previewWithdraw are basically unusable and revert the majority of the time.
There is on top of that no way in the ERC4626 standard to deal with this front-running situation.
We thus need an extension of the ERC4626 interface that allows to take such use cases into account, or at least if this cannot be fully standardized, a base system and implementation for protocols to efficiently deal with this illiquidity and front running issues while keeping user friendly interfaces.
Here we propose a framework to let people exit an ERC4626 strategy even if the assets corresponding to the value of the shares redeemed are not immediately available and with some anti front-running guarantees.
Our system relies on two additional functions on top of the base ERC4626 interface:
prepareRedeem: it should act as the redeem function when enough assets can be freed to redeem shares, and otherwise, it should fetch shares from owner and store an amount of shares which value will need to be reimbursed to the user as assets are made available in the contract