The following standard adapts ERC-4626 to support multiple assets or entry points for the same share token.
It adds a new share method to allow the ERC-20 dependency to be externalized.
This also enables Vaults which don’t have a true share token but rather convert between two arbitrary external tokens.
Lastly, it enforces ERC-165 support for Vaults.
### Multi-Asset Vaults
Multi-Asset Vaults share a single `share` token with multiple entry points denominated in different `asset` tokens. Multi-Asset Vaults MUST implement the `share` method on each entry point.
I’m not clear what is meant by an “entry point”. Does it mean a function on the vault contract? Or does it mean a separate contract altogether?
Also, do you know if there a reference implementation available?
Many thanks,
Kevin.
Many thanks @jeroen. A follow up question, which of these is correct:
a) A “multi-asset vault” is a separate contract in its own right, and can be thought of as “wrapping” the other vaults vaultA, vaultB underneath. If someone says “give me the address of your multi-asset vault” I can give them one address.
b) A “multi-asset vault” is actually just the logical grouping of vaultA and vaultB and share all taken together. If someone says “give me the address of your multi-asset vault” I would give them a collection of addresses.
Up till now I was thinking a) is true, but having seen your example, I think now it is b) that is true.
Great, thanks! I think it’d be helpful to new readers to add something explaining that to the ERC. There is no actual “multi-asset vault” contract, it is a logical construct of the component vault contracts.
Now imagine I’m looking at an ERC-7575 contract. I call share() to get the share token address, and it returns an external ERC-20 contract. Now on that share token contract, I call vault(asset address) to get the address of the vault for a given asset.
In this situation, am I able to work out ALL the assets that are supported by that share token contract?
Would there be value in allowing ERC-7575 entry point contracts to be fully backwards compatible with ERC-4626?
If I am following correctly, ERC-7575 entry points already have all the ERC-4626 functions, just they “should not” have ERC-20 functions (but can do to allow existing ERC-4626 vaults to be forwards compatible and look like ERC-7575 vaults).
Let’s say that a new ERC-7575 collection of entry point contracts did each have all the ERC-20 functions. The ERC-20 functions on each entry point could be passed through to the share token contract (with some extra dev work to give the entry point contracts the authorisations to adjust share token allowances, do share token transfers and so on).
This would mean existing ERC-4626 indexers wouldn’t have to change right away, the ERC-4626 ecosystem would still regard ERC-7575 as vaults.
Would there be value in allowing ERC-7575 entry point contracts to be fully backwards compatible with ERC-4626?
I think this is fine, and is not blocked in the current specification. I would not enforce it though, the “with some extra dev work to give the entry point contracts the authorisations to adjust share token allowances, do share token transfers and so on” part is quite complex. This can be done by implementing ERC-2771 on the share and setting the ERC-7575 entry points as trusted forwarders.
But indeed some ERC-7575 implementations might opt to do this, at which point they are fully compatible with ERC-4626.
Others might not, e.g. implementations of ERC-7540, since these are already non-compliant with ERC-4626, so it makes more sense to keep the vault implementation and share token simpler. (this is the case for the ERC-7540 implementation we have at Centrifuge).
Not easily onchain no. I don’t think it would make sense to store this in an array either, it would add significant gas overhead (for updating and reading the array).
What we could consider, is adding events to the share token, like
Yes I agree, adding a list is not ideal. The use case I was thinking of was just indexers. If I look at a share token contract, I can tell it is ERC-7575 (presumably the share token is also obligated to have ERC-165?). I might wonder “what entry points does this share token have?”. At present I can’t easily answer that by looking on-chain, but with the addition of those events on the share token I could collect those events and work it out. Indexers can then make sense of the vault without needing additional off-chain knowledge.
Maybe the ERC spec could have addVault etc functions defined against the share token, those are not explicitly mentioned.