ERC7540Form
Introduction
This is the Form
implementation for an ERC7540 vault. Denoted as Form ID 4 on all chains Superform is deployed on, it follows a similar structure and behavior to ERC4646Form
using with some changes in how deposits and redeems from the vault are conducted.
Core Concepts
The most significant feature change from ERC7540
to ERC4626
is the ability to process deposits and redeems in a two-step process.
The deposit / redeem flow will be as follows:
Firstly, the user requests a deposit (or) to redeem in the vault.
After time x, the request will be made available by some trusted actor, after which the actual deposit/redemption could be processed, and superpositions are minted.
To handle the two-step process, AsyncStateRegistry
is utilized to store the intermediary state till the request is made available.
The initial call from CoreStateRegistry
or SuperformRouter
to the form, all same-chain / cross-chain actions will request deposit/redemption from the vault.
claimDeposit
It can be called only by the AsyncStateRegistry
to process the second deposit step once the vault processes the request.
If the retain4626_
flag is unset, then an acknowledgment is sent from AsyncStateRegistry
of destination chain to source chain, and Superpositions are minted.
user_
The address of the user who made the deposit request
superformId_
The unique id of the superform to deposit to
amountToClaim_
Amount of assets that are made available to be deposited by the vault
retain4626_
Flag to represent if the user wants to mint superpositions post the deposit action
claimRedeem
Similar to claimDeposit
, this function allows AsyncStateRegistry
Post a successful request to process the second step of the redeem process.
user_
The address of the user who made the redeem request
superformId_
The unique id of the superform to deposit to
amountToClaim_
Amount of shares that are made available to be redeemed by the vault
maxSlippage_
The slippage that can be allowed post redeem
isXChain_
Flag to indicate if the redeem request made is same-chain (or) cross-chain
srcChainId_
The chainId from which the request is made
liqData_
The liquidity data to process the collateral bridging /swapping post-redeem
syncWithdrawTxData
Helper function to allow AsyncStateRegistry
to process redeem requests of DEPOSIT_ASYNC
vaults that require txData
update.
p_
The sync withdraw payload to redeem
Last updated