ERC-7575: Multi-Asset ERC-4626 Vaults

Extended ERC-4626 Interface enabling Multi-Asset Vaults

Abstract

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.

Motivation

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.

Specification

Definitions:

The existing definitions from ERC-4626 apply.

• Multi-Asset Vaults: A Vault which has multiple assets/entry points
• Pipe: A converter from one token to another (unidirectional or bidirectional)

Methods

share

The address of the underlying share received on deposit into the Vault. MUST return an address of an ERC-20 share representation of the Vault.

share MAY return the address of the Vault itself.

If the share returns an external token i.e. share != address(this):

• entry functions MUST increase the share balance of the receiver by the shares amount. i.e. share.balanceOf(receiver) += shares
• exit functions MUST decrease the share balance of the owner by the shares amount. i.e. share.balanceOf(owner) -= shares

MUST NOT revert.

- name: share
  type: function
  stateMutability: view

  inputs: []
  outputs:
    - name: shareTokenAddress
      type: address

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. The entry points SHOULD NOT be ERC-20.

Pipes

Pipes convert between a single asset and share which are both ERC-20 tokens outside the Vault.

A Pipe MAY be either unidirectional or bidirectional.

A unidirectional Pipe SHOULD implement only the entry function(s) deposit and/or mint.

ERC-165 support

Smart contracts implementing ERC-7575 MUST implement the ERC-165 supportsInterface function.

It MUST return the constant value true if 0x2f0a18c5 is passed through the interfaceID argument.

Share-to-Vault lookup

The ERC-20 implementation of share SHOULD implement a vault method, that returns the address of the Vault for a specific asset.

- name: vault
  type: function
  stateMutability: view

  inputs: 
    - name: asset
      type: address
    
  outputs:
    - name: vault
      type: address

Rationale

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.

Ability to externalize ERC-20 Dependency

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.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Jeroen Offerijns (@hieronx), Alina Sinelnikova (@ilinzweilin), Vikram Arun (@vikramarun), Joey Santoro (@joeysantoro), Farhaan Ali (@0xfarhaan), "ERC-7575: Multi-Asset ERC-4626 Vaults [DRAFT]," Ethereum Improvement Proposals, no. 7575, December 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7575.