One missing use case that is not supported by ERC-4626 is Vaults which have multiple assets or entry points such as liquidity provider (LP) Tokens. These are generally unwieldy or non-compliant due to the requirement of ERC-4626 to itself be an ERC-20.
This standard is intentionally flexible to support both existing ERC-4626 Vaults easily by the introduction of a single new method, but also flexible to support new use cases by allowing separate share tokens.
By allowing share != address(this), the Vault can have an external contract managing the ERC-20 functionality of the Share. In the case of Multi-Asset, this avoids the confusion that might arise if each Vault itself were required to be an ERC-20, which could confuse integrators and front-ends.
This approach also enables the creation of new types of Vaults, such as Pipes, which facilitate the conversion between two external ERC-20 tokens. These Pipes could be unidirectional (i.e. only for assets to shares via deposit/mint, or shares to assets via redeem/withdraw) or bidirectional for both entry and exit flows.
Including Share-to-Vault lookup optionally
The vault method is included to look up a Vault for a share by its asset. This enables integrations to easily query Multi-Asset Vaults.
This is optional, to maintain backward compatibility with use cases where the share is an existing deployed contract.
Backwards Compatibility
Existing ERC-4626 Vaults can be made compatible with ERC-7575 by adding a single share method that returns the address of the Vault.
Security Considerations
ERC-20 non-compliant Vaults must take care with supporting a redeem flow where owner is not msg.sender, since the ERC-20 approval flow does not by itself work if the Vault and share are separate contracts. It can work by setting up the Vault as a Trusted Forwarder of the share token, using ERC-2771.