ERC-8113: Series Accounting for Incentivized Vaults

ERCs
7

Thanks for pointing this out. While writing this ERC I was taking inspiration from ERC-7540, and was trying to maintain backwards compatibility with it. ERC-7540 itself maintain a backwards compatibility with ERC-4626 with the same method:

All ERC-7540 asynchronous tokenized Vaults MUST implement ERC-4626 with overrides for certain behavior described below.

Asynchronous deposit Vaults MUST override the ERC-4626 specification as follows:

  1. The deposit and mint methods do not transfer assets to the Vault, because this already happened on requestDeposit.
  2. previewDeposit and previewMint MUST revert for all callers and inputs.

Asynchronous redeem Vaults MUST override the ERC-4626 specification as follows:

  1. The redeem and withdraw methods do not transfer shares to the Vault, because this already happened on requestRedeem.
  2. The owner field of redeem and withdraw SHOULD be renamed to controller, and the controller MUST be msg.sender unless the controller has approved the msg.sender as an operator.
  3. previewRedeem and previewWithdraw MUST revert for all callers and inputs.

Would you recommend I should follow the same pattern (I agree that overriding so many methods to maintain backwards compatibility doesn’t seem very helpful practically) or just remove the need for backwards compatibility with ERC-4626 and/or ERC-7540?

For more context, while ERC-4626 is very widely used, the concept of ERC-7540 is getting just as popular but I have seen zero implementations in production that exactly match that spec. Protocols implement async 4626 vaults in their own ways. Perhaps it could be because of the over specification of ERC-7540 and hence it’s better to not try to maintain backwards compatibility to a standard which not really used in production anywhere?
Relevant discussion: EIP-7540: Asynchronous ERC-4626 Tokenized Vaults - #25 by nikollamalic