As described in this message I believe and extension ERC is required to standardize the EOA facing functions of ERC4626 vaults.
I think this extension makes a lot of sense. I like the idea of extending 4626 rather than creating a separate new standard to deal with certain use cases as is the case here: EIP-5115: Super Composable Yield Token.
Something that I was wondering about:
What would be the default behaviour of calling a function without the min/max/Shares/Assets as per 4626 alone?
- The user/integrator should build in their own slippage protection?
- IF a contract extends 4626 with 5143, the overloaded functions are there to customise the slippage, while the base 4626 functions should have slippage protection built-in?
The ladder would be better in my opinion.
This would make a true standard, since the user could handle each contract that is 4626 the same way, without risking being sandwiched with one 4626 Vault while being totally safe with another. One that extends 4626 with 5143 while the other doesn’t.
We should make sure to protect users/integrators in either case. That is why the reference implementation should be different. The 4626 deposit function should work out a min/max/Shares/Assets and call the 5143 deposit function with that value. While the functions within 5143 can customise the slippage and potentially save gas if the calculation is done off-chain.
In my opinion, this would be a better way of extending a standard while keeping the base standard usable even with the extension.
I would therefore add:
- A contract that is 4626 with the 5143 extensions should require the 4626 deposit/mint/redeem/withdraw to handle slippage
- The 5143 deposit/mint/redeem/withdraw functions are to customise slippage and save gas if the calculation is done off-chain or to be called directly from another smart contract if the slippage logic is to be customised.
Making each 4626 standardised and functioning in an expected way is the goal.
My ERC4646, the deposit/mint/redeem/withdraw function can be subject to slippage, and have no specific protection.
They are designed to be called by smart contracts, not by EOA. Using the preview allows them to estimate slippage and only execute the operation if they accept it. This design works if the preview call, the decision making, and the operation are in the same transaction which smart contracts can do, but not EOA.
This is why we need an alternative workflow for EOAs. Backward compatibility dictates that using 5143 on top of 4626 does NOT modify the 4626 behavior. in particular, it doesn’t change anything about slippage possibly happening.
I’d recommend requiring support for EIP-165 so that wallets can detect these additional functions easily.
For some reason, EIP-4626 doesn’t include EIP-165 support… So I’m not sure what should/shouldn’t be in the interfaceID.