This standard extends EIP-4626 to support lock-in periods.
Motivation
The EIP-4626 standard defines a tokenized vault allowing users (contracts or EOAs) to deposit and withdraw underlying tokens at any time. However, there exist cases where the vault needs to lock the underlying tokens (perhaps to execute certain strategies). During the lock-in period, neither withdrawals nor deposits should be allowed. This standard extends the EIP-4626 to support lock-in periods and handle scheduled deposits and withdrawals during them.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
All vaults that follow this EIP MUST implement EIP-4626 to provide basic vault functions and EIP-20 to represent shares.
Definitions
asset: The underlying EIP-20 token that the vault accepts and manages.
share: The EIP-20 token that the vault issued.
locked: A status of the vault. When the vault is locked, user can’t withdraw or deposit assets from the vault.
unlocked: A status of the vault. When the vault is unlocked, user can withdraw or deposit assets from the vault.
round: The period that the vault is locked.
View Methods
isLocked
The current state of the vault.
true represents a vault is in the locked state, and false represents a vault is in the unlocked state.
The standard is designed to be a minimal interface. Details such as the start and end of a lock-in period, and how the underlying tokens are being used during the lock-in period are not specified.
There is no function for scheduling a withdrawal, since during the lock-in period, the share price is undetermined, so it is impossible to determine how many underlying tokens can be withdrawn.
Backwards Compatibility
The deposit, mint, withdraw, redeem methods for EIP-4626 should revert when the isLocked is true to prevent issuing or burning shares with an undefined share price.
Security Considerations
Implementors need to be aware of unsettled scheduled deposits and redemptions. If a user has scheduled a deposit or redemption but does not settle when the isLocked is false, and then settles it after several rounds, the vault will process it with an incorrect share price. We didn’t specify the solution in the standard since there are many possible ways to solve this issue and we think implementors should decide the solution according to their use cases. For example:
Not allow the isLocked to become true if there is any unsettled scheduled deposit or redemption
Force settling the scheduled deposits or redemptions when the isLocked becomes true
Memorize the ending share price for each round and let the users settle according to the share prices
Anderson Chen (@Ankarrr), Martinet Lee <martinetlee@gmail.com>, Anton Cheng <antonassocareer@gmail.com>, "ERC-6229: Tokenized Vaults with Lock-in Period [DRAFT]," Ethereum Improvement Proposals, no. 6229, December 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6229.