Metera Protocol V.1
  • 🚀Welcome to Metera Protocol Documentation
  • ♟️Content
    • What is Metera?
      • About us
      • Key Features
      • Metera Tokenized Indexes
        • Why MTKs?
        • Minting MTK Shares
        • Auto-balancing Algorithm
      • Metera Token ($METERA)
        • Utility and Incentives
        • Deflationary Tokenomics and Burning Mechanisms
      • Metera DAO MTKs
        • Types of DAO MTKs and Creation Process
          • DAO-Owned MTKs (DOM)
          • Partially DAO-Owned MTKs (PDOM)
          • Strategic Partnership DOM (SPDOM)
    • Testnet v2
      • Minting and Burning
      • Faucet
      • Index Creation
    • Indices (MTKs)
      • DePin Cardano Index ($mDePin)
  • 🔬Metera WIKI
    • Tokens
    • Users
    • Roadmap
  • 🌐Governance
    • Governance
      • Dao Treasury
      • Protocol Owned Liquidity (POL)
    • Tokenomics
  • Linktree
Powered by GitBook
On this page
  • Deposit / Withdraw operation acceptance
  • Examples
  1. Content
  2. Metera Platform V.1 Overview

Balance Approximation

Metera - Balance Approximation on Deposit and Withdraw Operations

Last updated 6 months ago

Currently in V1, underlying assets can´t be removed or added. To address this need, in order to re-balance the index to adjust the weights of assets to match the target weights, the rebalancing is done via transactions (e.g., making a deposit or withdraw).

Deposit / Withdraw operation acceptance

The acceptance or rejection of a deposit or withdraw operation relies only on the weights present in the portfolio and the states of the MTK before and after the operation, more precisely, on the weights of the tokens in the MTK. We propose to measure the L1 distance between the weights of the current MTK and the weights indicated by the oracle, and the L1 distance between the weights of the MTKafter the interaction and the weights indicated by the oracle. If the latter valuation is lower, the transaction is accepted.

Let’s define:

  • target balance as the weights vector described in the MTK,

  • current balance as the weights vector that can be measured from the MTK´s value,

  • distance to target of a token as the absolute value of the difference between the weights of the token in the current balance and the target balance,

  • balance measure of an MTK as the sum of the distances to the target of every asset in the MTK, divided by the total number of assets.

We say that one of these operations approximates the target balance if the balance measure of the MTK after the operation is lesser or equal to the balance measure before the operation. In this sense, we can define a boolean function approximatesBalance, which takes the weights vector before and after the operation, and the weights vector provided by the MTK, and returns true if the condition mentioned above is met, otherwise it returns false:

Examples

Deposit Operation Fails

Deposit Operation Succeeds

Withdraw Operations

Withdraw operations examples are analogous, since the evaluation of the balance approximation criteria only depends on the index input and outputs states, and not on other inputs/outputs, mint/burn of MTK tokens, etc.

Deposit Function

Users may want to decide how much ADA they want to deposit in the index. We need then to have functionality that supports this input, and calculates an appropriate set of assets such that the whole input can be added to the index. This of course considers the needed amount of tokens for the index to be balanced, and if there was a remaining amount of user Ada input, then calculate the tokens to add according to the balance required.

♟️
[1]
In this example we can see a deposit operation in which the user submits a set of asset1, asset2 and asset3, in such a way that the balance measures of the index do not meet the acceptance criteria described above as it doesn’t approximate the balance described in the index, therefore the transaction will fail.
In this example we can see that the balance in the index indeed approximates the balance described by the index