Then it would be great to explicitly specify it in the section ERC-7540: Asynchronous ERC-4626 Tokenized Vaults that redeem flow is not backward compatible .
Update log
- 2024-12-03: Event names were fixed, PR #670
requestRedeem and redeem both expect the argument shares.
Assume the following situation that Alice calls requestRedeem 3 times with shares 30, 50, 20 respectively which makes total shares requested to redeem = 100.
Also assume that requestRedeem returns 0 as request id.
ERC7540 says:
When
requestId==0, the Vault MUST use purely thecontrollerto discriminate the request state. The Pending and Claimable state of multiple requests from the samecontrollerwould be aggregated.
This means that in redeem, we must redeem all claimable shares. The confusing thing now is that what if alice passes 80 as shares. This would mean that she only wants to redeem assets of 80 shares, which kind of goes against the ERC7540 specification statement about request id = 0.
What should the decision be here so the code still obeys the ERC7540 specification ?
This EIP is one of the biggest mistakes ever. Forcing 4626 backwards compatibility is same as if the car manufacturers decided to put actual horses into cars. There is no point and I did not see a single implementation that retains this backwards compatibility without being hacky and breaking 4626.
We need a new standard for async vaults, otherwise we will have to endure tons of problematic code in the future.