Skip to main content

Majora ERC4626 Vaults

What is an ERC-4626 Vault?​

An ERC-4626 vault is a standard interface for Ethereum smart contracts, specifically designed for vaults that accept token deposits and manage them to generate yields. The standard is built on top of the ERC-20 token interface, meaning it is compatible with any ERC-20 tokens.

The primary goal of this standard is to provide a common framework for vaults that manage investment strategies in yield farming or other yield-generating mechanisms. This allows better interoperability between different DeFi projects, making it easier to integrate various vaults and strategies with standardized interfaces.


Key Features​

No code DeFi strategy deployment​

Majora application allowing users to deploy custom DeFi strategies without writing a single line of code. Our platform enables anyone to create ERC-4626 and setup a DeFi strategy using an intuitive web interface. This no-code environment democratizes access to complex yield strategies, making it easier than ever to optimize returns in the DeFi ecosystem.

overview

You can find the internal strategy setup documentation here


Ownership defined by ERC3525​

When a vault is created, an ERC3525 contract is also deployed. This ERC3525 token is used for defining the current owner of the vault (tokenId 1), who has the authority to modify vaults parameters and manage the distribution of creator fees through the values assigned to different tokenIds of the ERC3525.

warning

If the tokenId 1 of an ERC3525 is transfered, the vault ownership will be transfered to the receiver too


Vault middleware strategies​

Majora introduces three vault middleware strategy that enhances flexibility and security.

info

Middleware strategy is setup on the vault deployment and can't be changed. There is only the middleware configuration that can be changed by the owner (add address to the whitelist etc. )

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


Vault 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.

Automation Fees​

Automation fees are used to finance vault operations by swapping automation fees to StrategOperatingPaymentToken. By converting automation fees to StrategOperatingPaymentToken, the protocol ensures efficient financing on operations the vault strategy.


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.

Automated vault management​

To be operated by Majora infrastructure, vaults have to be sponsorized by its creator (or any other address). To sponsor a vault, a user need Strategy Operating Payment Token (SOPT) balance.

Strategy Operating Payment Token (SOPT)​

Basically, it is a token following the ERC20 standard which wrap the gas token of the chain where the protocol is deployed and it is not transferable.

In addition of ERC20 function there is some additional functions to dedicate funds to the operation of a vault with approveOperation function which is working like a traditional ERC20 approval. When an operation is executed, SOPT token is burn from the sponsor balance and gas token is transfered to the operator to refund the operation gas cost.

Operators​

Operators are whitelisted entities who perform various actions on the vaults when necessary, using the MajoraOperatorProxy contract.

These actions include:

  • Rebalancing strategies
  • Rebalancing position managers
  • Harvesting strategies
  • Stopping strategies

For these actions to be executed by operators, vaults must have available gas (gas costs of operations are supported tiers party) via the SOPT.

info

In the beginning, all operators of the protocol will be centralized by Majora protocol team and will be decentralized later.