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?
or
- 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.