Ok thanks Jeroen. A few more points:
-
The section titled “backwards compatibility” shouldn’t that read “forwards compatibility”? This is because it talks about making existing ERC-4626 vaults forwards compatible with ERC-7575. When new multi-asset vaults are created, if we follow the standard, the vaults should not be ERC-20. So therefore, in general, we’d expect ERC-7575 vaults to not be backwards compatible with ERC-4626.
-
The section titled “pipes”, could you explain that further, maybe supply examples of how uni-/bi-directional vaults would look? As it stands, when I read this sentence “a unidirectional Pipe SHOULD implement only the entry function(s)
depositand/ormint” it makes it sound like assets can only move into the vault and never out of the vault. Presumably a vault that is a pipe needs a function asset() that gives the address of the external asset? (similar to share() providing external share address). Do non-pipe vaults need that function too? -
In the section on “Specification” under sub-section “Definitions” it says "existing definitions from ERC-4626 apply. But then under the sub-sections “Methods” it doesn’t say “also include all the methods and events from ERC-4626”. I think it is implied, but it should be spelled out.
-
I think a sentence near the start explaining that there is no such thing as an address of a multi-asset vault, rather a multi-asset vault is a logical grouping of ERC-7575 compliant “component” vaults that happen to share the same share token. It might just be me, but it took me a while to appreciate that. I’d thought a multi-asset vault was a separate contract that “wrapped” the component vaults.