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.
claimRedeem
Similar to claimDeposit
, this function allows AsyncStateRegistry
Post a successful request to process the second step of the redeem process.
syncWithdrawTxData
Helper function to allow AsyncStateRegistry
to process redeem requests of DEPOSIT_ASYNC
vaults that require txData
update.
Last updated