Vault Listing Guidelines
Updated this week

Superform currently supports ERC-4626 vaults. There are certain conditions that should be kept in mind when listing ERC-4626 vaults on Superform, largely to highlight some non-standard vault behavior.

Mandatory Requirements:

  • The vault must issue transferrable ERC-4626 shares

    • Per EIP-4626, a vault can be non-transferable. However, if a vault token is non-transferrable, the user would not be able to rescue such tokens in an emergency situation through the Emergency Queue mechanism implemented in the Superform contracts. Therefore they are not officially supported.

  • The redeem() return value must exactly match the assets received after redemption

    • Even if there is a 1 WEI difference between the return value of the redeem() function and the amount of assets returned to the receiver, the vault implementation becomes incompatible with Superform.

  • The vault must execute calls to deposit() and redeem() in one atomic transaction

    • If the vault requires any async actions such as requesting to deposit or requesting to redeem the vault implementation is incompatible with Superform. Async vaults will be supported in the future as long as they adhere to EIP-7540.

  • The vault must revert if it fails to consume the entire assets passed into the deposit() function

    • If there is a max deposit limit, and the passed in value exceeds the limit, the vault should not partially consume the passed in assets.

  • The vault must not have any msg.sender based limitations to redeem() or deposit()

    • Superform creates a common interface for vaults so they can interact with the core protocol. These are called Superforms. Superforms are what ultimately interact with the vault implementations.

  • The vault must implement the name() and symbol() functions to reflect the underlying token’s metadata

  • During deposit(), the underlying tokens must always be moved from the msg.sender address

    • We do not support vaults with an additional flow in which the vault contract owns the underlying tokens before the deposit() execution.

  • During redeem(), the vault shares must always be moved from the msg.sender address

    • We do not support vaults with an additional flow in which the shares are transferred to the Vault contract before the redeem() execution.

Other Requirements:

  • Superform off-chain infra depends on convertToShares() to determine the number of vault shares during the intent data generation for the user (for cross-chain slippage protection)

    • Because the infrastructure works cross-chain with latency, the vault users may face high deposit failure rates if this value is inaccurate or volatile. We would advise against listing such vaults on Superform.

  • Superform keepers use previewRedeemFrom() to generate cross-chain settlement data following a successful redeem() call

    • There isn’t much latency compared to the aforementioned deposit case, but there is a chance of a redeem() failure if the values are inaccurate or volatile.

  • The Superform app uses convertToAssets() for portfolio representation on its front end.

    • If these values are off, user vault shares might be represented incorrectly.

Notes:

  • Superform only uses the deposit() and redeem() functions. The withdraw() and mint() functions are not used inside the protocol to interact with 4626 vaults.

Did this answer your question?