Vault Configuration
Middleware strategies
A middleware strategy refers to a specific strategy or set of rules that govern how users can interact with the vault. There are different types of middleware that can be applied to a vault, each imposing certain conditions or restrictions on user actions. The middleware strategy setup in a vault is immutable. There are three middleware strategy on StrategVault contract:
Public
This middleware type allows any user to interact with the vault without any restrictions. Users can deposit, withdraw and transfer shares without any special conditions.
Whitelist
In this middleware type, only whitelisted addresses are allowed to interact with the vault. Users need to be explicitly whitelisted to deposit assets in the vault.
Holders
The Holder middleware type imposes restrictions based on the assets holdings of the user. Users need to meet certain criteria related to an asset to interact with the vault. These criteria include minimum holding amounts of a specific token to be able to deposit assets on the vault
Customizable configurations
Vault buffer
Vaults feature an asset buffering system to facilitate user deposits and withdrawals. The amount of assets remaining in the buffer is defined by the vault owner using two parameters:
Buffer size: The percentage of assets that should remain in the buffer.
Derivation: The tolerated deviation of the buffer relative to its total assets.
When users deposit assets into a vault, these assets are directly placed in the buffer. If the deposited amount in the buffer falls outside the range (less than buffer size minus derivation or more than buffer size plus derivation), the operators will rebalance the vault to restore the buffer to the desired size.
Vault fees
There is different kinds of fees taken on vault performance.
Performance fees are calculated based on the profits generated by the vault. These fees are typically a percentage of the profits earned by the vault and are charged to incentivize the protocol and vault creators.
There is three configurable fees on a vault:
Creator Fees
This fees are sent to the ERC3525 with the addRewards function. It will be distributed to the different owner of ERC3525 token based on their token values.
Harvest Fees
Harvest fees are used to finance vault operations by swapping harvest fees to StrategOperatingPaymentToken.
By converting harvest fees to StrategOperatingPaymentToken, the protocol ensures efficient financing on operations the vault strategy.
Protocol fees
Protocol fees are charges imposed to support the ongoing development and maintenance of the protocol. These fees are essential for ensuring the sustainability and innovation of the protocol.
This fees are set to a common value to every vault and can be customizable by a governance decision.
User timelock
The Timelock is a security feature implemented to enforce a delay between a deposit and a withdraw or a transfer. This delay ensures that a user can't use flashloan easily to manipulate vault internal metrics. It enhancing the security and stability of the vaults.
Vault TVL Limits
The TVL limits ensure that the vault does not exceed certain thresholds. These limits are configured using the VaultFactory and include:
Minimum User Deposit: The minimum amount of shares a user must mint.
Maximum User Deposit: The maximum amount of shares a user can mint.
Minimum Vault Deposit: The minimum amount of assets the vault must to have before being operated.
Maximum Vault Deposit: The maximum total shares that the vault can mint.
Configuration changes queue
The StrategVaultFactory implements a configuration change queue mechanism to manage the settings of individual vaults. This system schedules changes to customizable configurations to be applied after a delay to give the time to shares holders to exit their liquidity before the changes are applied.
The change process is the following:
Initiation: The vault owner initiates a configuration change, which is then added to the queue with the current timestamp.
Waiting Period: The change remains in the queue for at least the timelock duration (72 hours).
Application: Post-timelock, the change is ready to be applied to the vault.
Execution: The change is executed, updating the vault's configuration.
NB: The first changes (applied post vault deployment) doesn't have delay period
Last updated