Superform Labs

Superform currently supports <a href="https://erc4626.info/" rel="nofollow noopener noreferrer" target="_blank">ERC-4626</a> 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. ​

The vault must issue transferrable ERC-4626 shares

- Per <a href="https://eips.ethereum.org/EIPS/eip-4626" rel="nofollow noopener noreferrer" target="_blank">EIP-4626</a>, 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 <a href="https://docs.superform.xyz/periphery-contracts/emergencyqueue" rel="nofollow noopener noreferrer" target="_blank">Emergency Queue</a> mechanism implemented in the Superform contracts. Therefore they are not officially supported.

The <code>redeem()</code> return value must exactly match the assets received after redemption

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

The vault must execute calls to <code>deposit()</code> and <code>redeem()</code> 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 <a href="https://eips.ethereum.org/EIPS/eip-7540" rel="nofollow noopener noreferrer" target="_blank">EIP-7540</a>.

The vault must revert if it fails to consume the entire <code>assets</code> passed into the <code>deposit()</code> 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 <code>msg.sender</code> based limitations to <code>redeem()</code> or <code>deposit()</code>

- Superform creates a common interface for vaults so they can interact with the core protocol. These are called <a href="https://docs.superform.xyz/periphery-contracts/superformfactory" rel="nofollow noopener noreferrer" target="_blank">Superforms</a>. Superforms are what ultimately interact with the vault implementations.

The vault must implement the <code>name()</code> and <code>symbol()</code> functions to reflect the underlying token’s metadata

During <code>deposit()</code>, the underlying tokens must always be moved from the <code>msg.sender</code> address

- We do not support vaults with an additional flow in which the vault contract owns the underlying tokens before the <code>deposit()</code> execution.

During <code>redeem()</code>, the vault shares must always be moved from the <code>msg.sender</code> address

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

- The vault must issue transferrable ERC-4626 shares
 - Per <a href="https://eips.ethereum.org/EIPS/eip-4626" rel="nofollow noopener noreferrer" target="_blank">EIP-4626</a>, 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 <a href="https://docs.superform.xyz/periphery-contracts/emergencyqueue" rel="nofollow noopener noreferrer" target="_blank">Emergency Queue</a> mechanism implemented in the Superform contracts. Therefore they are not officially supported.
- The <code>redeem()</code> return value must exactly match the assets received after redemption
 - Even if there is a 1 WEI difference between the return value of the <code>redeem()</code> function and the amount of assets returned to the <code>receiver</code>, the vault implementation becomes incompatible with Superform.
- The vault must execute calls to <code>deposit()</code> and <code>redeem()</code> 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 <a href="https://eips.ethereum.org/EIPS/eip-7540" rel="nofollow noopener noreferrer" target="_blank">EIP-7540</a>.
- The vault must revert if it fails to consume the entire <code>assets</code> passed into the <code>deposit()</code> 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 <code>msg.sender</code> based limitations to <code>redeem()</code> or <code>deposit()</code>
 - Superform creates a common interface for vaults so they can interact with the core protocol. These are called <a href="https://docs.superform.xyz/periphery-contracts/superformfactory" rel="nofollow noopener noreferrer" target="_blank">Superforms</a>. Superforms are what ultimately interact with the vault implementations.
- The vault must implement the <code>name()</code> and <code>symbol()</code> functions to reflect the underlying token’s metadata
- During <code>deposit()</code>, the underlying tokens must always be moved from the <code>msg.sender</code> address
 - We do not support vaults with an additional flow in which the vault contract owns the underlying tokens before the <code>deposit()</code> execution.
- During <code>redeem()</code>, the vault shares must always be moved from the <code>msg.sender</code> address
 - We do not support vaults with an additional flow in which the shares are transferred to the Vault contract before the <code>redeem()</code> execution.

Superform off-chain infra depends on <code>convertToShares()</code> 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 <code>previewRedeemFrom()</code> to generate cross-chain settlement data following a successful <code>redeem()</code> call

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

The Superform app uses <code>convertToAssets()</code> for portfolio representation on its front end.

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

- Superform off-chain infra depends on <code>convertToShares()</code> 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 <code>previewRedeemFrom()</code> to generate cross-chain settlement data following a successful <code>redeem()</code> call
 - There isn’t much latency compared to the aforementioned deposit case, but there is a chance of a <code>redeem()</code> failure if the values are inaccurate or volatile.
- The Superform app uses <code>convertToAssets()</code> for portfolio representation on its front end. 
 - If these values are off, user vault shares might be represented incorrectly.

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

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

Mandatory Requirements:

Other Requirements:

Notes: