Superform v1
  • Introduction
  • Components
    • Protocol
    • Keepers
    • API
    • App
  • E2E Flows
    • Same-chain Deposit
    • Cross-chain Deposit
    • Same-chain Withdrawal
    • Cross-chain Withdrawal
  • Periphery Contracts
    • SuperformRouter
      • SuperformRouterPlus
      • SuperformRouterPlusAsync
    • PayMaster
    • PaymentHelper
    • EmergencyQueue
    • SuperformFactory
    • Forms
      • ERC4626Form
      • ERC5115Form
      • ERC7540Form
    • SuperPositions
      • ERC1155A
    • RewardsDistributor
  • Core Contracts
    • State Registries
      • CoreStateRegistry
      • AsyncStateRegistry
      • PayloadHelper
    • AMB Implementations
      • LayerzeroImplementation
      • LayerzeroV2Implementation
      • WormholeARImplementation
      • HyperlaneImplementation
      • AxelarImplementation
    • Broadcasting
      • BroadcastRegistry
      • WormholeSRImplementation
    • Bridge Validators
      • LiFiValidator
      • SocketValidator
      • SocketOneInchValidator
      • DebridgeValidator (and forwarder)
      • OneInchValidator
    • DstSwapper
    • Settings
      • SuperRBAC
      • SuperRegistry
  • SuperVaults
    • SuperVaults
  • Resources
    • Deployment Addresses
    • Subgraphs
      • Protocol Level Entities
      • Form Related Entities
      • Deposits and Withdrawals
      • SuperPosition Events
      • External Entities
    • Infrastructure Integrations
    • Security & Audits
    • Protocol License
    • Glossary
    • Protocol Multisig
    • Superform Labs Socials
Powered by GitBook
On this page
  • Introduction
  • Core Concepts

Was this helpful?

  1. Periphery Contracts
  2. Forms

ERC5115Form

Introduction

This is the Form implementation for a ERC5115 vault. Denoted as Form ID 3 on all chains Superform is deployed on, it follows a similar structure and behaviour to ERC4646Form using with some changes in the way deposits and redeems from the vault are conducted.

Core Concepts

The biggest feature change from ERC5115 to ERC4626 is the inexistent of the concept of asset . Instead, vaults support multiple tokenIn addresses for deposits and multiple tokenOut addresses for redeems. As superform operates under one underlying asset constraint (imposed by SuperformFactory) a ERC5115to4626Wrapper (and its corresponding factory) were created to adapt the mechanism of ERC5115 to ERC4626. This wrapper allows creators to set a tokenIn/tokenOut pair to represent a given ERC5115Form. The tokenIn is regarded as the asset as per the ERC4626 definition and tokenOut is considered the default tokenOut. These remain immutable in the wrapper.

Superform can support all tokenIn/tokenOut versions of a given ERC5115 by allowing all permutations of these to be created within wrappers. This logic is abstracted away from the end user who sees only a single ERC5115Form to deposit to.

Last updated 10 months ago

Was this helpful?