ERC4626TimelockForm
Introduction
This is the Form
implementation for a timelocked ERC4626 vault. Denoted as Form ID 2 on all chains Superform is deployed on, it inherits from ERC4626FormImplementation
, using its overrides and action internal functions in an unchanged manner. Deposit flow is unchanged, but withdrawals are substantially different than ERC4626Form
.
Core Concepts
There are two main changes to ERC4626Form
that ERC4626TimelockForm
implements to support timelocked vaults. On any withdrawal case (direct or crosschain), instead of redeeming from a vault, two internal functions are called:
function
_requestUnlock
, which calls therequestUnlock
function from a timelockVault (must be compatible with IERC4626TimelockVault.sol interface). This initiates the unlock process and a timestamp with the date of the unlock is returnedfunction
_storePayload
, keeping handy information about the payload, including the timestamp created above.
At the end of the storePayload
call, this information is sent to the TimelockFormStateRegistry
, where it can be processed by the keeper after the end of the unlock process.
withdrawAfterCoolDown
Once the unlock process is over, a keeper can finalize the timelocked payload by calling finalizePayload
on TimelockFormStateRegistry
, which in turn calls withdrawAfterCooldown
in this form. This call will revert if actioned before the unlock timestamp. This operates just like a normal withdrawal, with a redeem from the vault and a swap or bridge done after to bring the output tokens to the beneficiary.
withdrawAfterCooldown
Name | Description |
---|---|
| Number of shares to withdraw from the vault |
| The struct containing the |
TwoStepsPayload
Name | Description |
---|---|
| uint8 boolean. Indicates if the withdrawal call is cross-chain or not |
| address of the underlying recipient |
| uint64 of the originating EVM |
| uint256 of the timestamp with the unlock time |
| Refers to the |
| Refers to TimelockStatus, an enum with params: |
Last updated