ERC-7575 Multi-asset ERC-4626 vault (Multi-Asset ERC-4626 Vaults)
Final · Vaults & DeFi · created 2023-12-11
A vault standard that extends ERC-4626 so that multiple asset entry points can be connected to a single share token. By separating the vault from the share token, it also allows vaults that convert between two external tokens.
Why it is needed
The ERC-4626 standard requires the vault contract itself to be the ERC-20 token that represents shares. As a result, only a structure where one vault is paired with one asset is naturally supported. Building a vault with multiple assets or multiple entry points, such as a liquidity provider (LP) token, either creates a separate share token for each vault, which is inconvenient to handle, or makes it impossible to follow the standard at all. It is also hard to use an already deployed token as the share, or to build a contract that converts between two different external tokens in the shape of ERC-4626. ERC-7575 separates the ERC-20 functionality from the vault and adds a share method that reports the address of the share token, which brings these structures within the standard.
In depth
A vault with only the ERC-20 part removed from ERC-4626
An ERC-7575 vault must implement ERC-4626, but must not implement the methods and events that correspond to ERC-20. The rest of ERC-4626, which handles deposits, withdrawals and conversions, is left as is, and only the requirement that the vault itself be the share token is removed. Instead, a newly added view function share reports the address of the ERC-20 share token received on deposit. Because share may return the vault's own address, an existing ERC-4626 vault can follow this standard by adding just one method.
Obligations of the share method
share must never revert. If the share is a separate token outside the vault (share != address(this)), the entry functions must increase the receiver's share balance by shares (share.balanceOf(receiver) += shares), and the exit functions must decrease the owner's share balance by shares (share.balanceOf(owner) -= shares). Thanks to this rule, deposit and withdrawal results appear in the same way as in ERC-4626 even when share accounting lives in a token outside the vault.
Structure of a multi-asset vault
A multi-asset vault is a structure in which multiple entry points marked with different asset values share a single share token. The original text defines it as a set of ERC-7575 contracts, each acting as the entry point for a specific asset, connected to one common share token. Each entry point must implement the share method, and it is recommended that the entry point itself not be an ERC-20. The reference implementation shows TokenAVault and TokenBVault each having a different asset but returning the same Share contract address as share.
Pipe: a converter between two external tokens
A pipe is a vault that converts between asset and share, which are ERC-20 tokens outside the vault, and it can be one-directional or bidirectional. A one-directional pipe is recommended to implement only the entry functions deposit or mint, and not redeem or withdraw. On entry, it is recommended to lock or burn msg.sender's asset and mint or transfer share to the receiver, and on exit in a bidirectional pipe, it is recommended to lock or burn the owner's share and mint or transfer asset to the receiver.
The vault lookup from a share
The ERC-20 implementation of the share token is recommended to implement a vault method that takes an asset address and returns the address of the vault that handles that asset. It is recommended to emit a VaultUpdate event when the vault linked to the share changes. This lookup helps integrators explore multi-asset vaults easily, but it is left optional rather than mandatory for compatibility with cases where an already deployed existing contract is used as the share.
Identifying each other with ERC-165
An ERC-7575 vault must implement the ERC-165 supportsInterface function and must return true when 0x2f0a18c5 is passed as the interfaceID. A share contract is recommended to implement supportsInterface, and if it does, it must return true for 0xf815c03d. Integrators can use these values to confirm which contract is an ERC-7575 vault and which token is its share without reading the code.
Not fully compatible with ERC-4626
Because the ERC-20 functionality has been removed, an ERC-7575 vault is not fully compatible with ERC-4626. When the share token is separate from the vault, integration code that expects ERC-4626 cannot handle share balances or transfers directly at the vault address and must go through the token address reported by share. Conversely, if share is implemented to point to the vault itself, an existing ERC-4626 vault can easily follow this standard. The status of this standard is finalized as Final.
Things to watch out for
- Approval flow when the vault and share are separate: A vault that does not implement ERC-20 must be careful when it supports a redeem flow where the owner is not msg.sender. When the vault and share are separate contracts, the ERC-20 approval (approve) flow does not work on its own. The original text explains that it can work if the vault is set as the Trusted Forwarder of the share token using ERC-2771.