🔬
Product Docs
  • Welcome to AZKA FINANCE
  • AZKA Token Murabaha Overview
    • General
    • System Components
    • Protocol Architecture
    • Token Types
    • Use Cases
    • AZKA RoadMap
  • Murabaha Pools V1
    • Providing Liquidity
    • Pool Metrics
    • vROI
    • Murabaha Fee Rate Curve
    • Shariah Considerations
  • Executing Murabaha V1
    • Pre-Requisites
    • Initiating Murabaha
    • Executing Murabaha
    • Quote Methodology
      • Amount of Murabaha Token Required (AMTR)
      • Required Amount of Currency (RAC)
    • Shariah Considerations
  • Managing Murabaha V1
    • Managing Murabaha
    • Liquidation Parameters
    • Liquidation Mechanics
    • Shariah Considerations
  • Token Murabaha Risk Framework
    • General
    • Asset Risk
    • Liquidity Pool Risk
    • Liquidation Risk
    • Risk Parameters
  • AZKA Token Design and Tokenomics
    • General
    • Specific Utilities (AZKA, vAZKA, dLP)
    • Token Distribution
    • vAZKA
      • vAZKA Reward Distribution
    • dLP (Dynamic LP)
      • Initiating dLP
      • vAZKA Murabaha Eligibility
      • Managing Eligibility
      • Claiming vAZKA
  • Governance
    • General
    • DAO Structure and Policies
    • azTeams
  • Developer Docs
    • Murabaha Pools
    • Executing Murabaha
    • Liquidations
Powered by GitBook
On this page
  1. Executing Murabaha V1
  2. Quote Methodology

Required Amount of Currency (RAC)

When dealing with a single pool governed by some AMM curve, it is possible to deduce the feasible token amounts by accounting for the impact of MEV/Arbitrage on the pool. However, DEX aggregators use various liquidity sources to facilitate swaps. It is almost impossible (or a significant undertaking) to assume what will happen to the aggregated liquidity sources as a result of price disparity and MEV/Arbitrage. What we can do however, is give an approximation or worse case scenario.

The Murabaha Aggregator/Order Book queries the DEX aggregator in the following way :

  1. What amount (A) of Murabaha token (i.e. UNI) do we need to sell to obtain B amount of Currency token (i.e. USDT)

  2. What amount (C) of the Currency Token (USDT) do we need to swap in order receive the amount (A) of the Murabaha token specified in the first query.

  3. This amount (C) is then appended to account for the slippage in order to derive the base debt that will be owed to the AZKA pool as follows:

Dex Aggregator Quote (Q)=Amount (C)×(1+(2×slippage tolerance)){\small \text{Dex Aggregator Quote (Q)} = \text{Amount (C)} \times \left(1 + (2 \times \text{slippage tolerance)} \text{}\right)}Dex Aggregator Quote (Q)=Amount (C)×(1+(2×slippage tolerance))

We are essentially querying the DEX aggregator for both transactions simultaneously based on current on-chain liquidity dynamics, without really knowing what will happen after the first transaction. Price impact is accounted for because the query derives values based on the liquidity dynamics at the time of the query. Hence the query is in essence reflective of the worst case scenario where the liquidity returns to the same state (state at time of the query) due to Arbitrageurs/MEV. Swap fees are accounted for but slippage is not and we can assume the taker may incur slippage twice. Experiencing this slippage or having a reverted transaction is a possibility that has been highlighted in previous sections.

The DEX Aggregator Quote (Q) value is essentially the amount of currency token (USDT) and represents the base debt (ex additional protocol fees) in the currency token that the user would would owe the pool. The DEX aggregator quote/base debt is what will be taken from the pool to facilitate the takers request.

If price impact is greater than 1% the calculation starts to lose accuracy and may not be feasible to use as a good approximation. This is because we are receiving both quotes before any transaction is executed. We can assume that aggregated on-chain liquidity will return to its original state but if price impact is large it could cause a more broad market price movement that will make on-chain liquidity and price less predictable. It is also not a bad idea to set a small buffer on the RAC value just in case.

It is important to note that the calculations and framework explored in this section are based on the assumption that Murabaha takers are conducting all of their activities on-chain. Calculations such as the RAC may not be necessary if users utilise a Centralised Exchange for the second transaction or can source a better on chain price. In such a scenario the AMTR calculation would be sufficient. The RAC calculation also assumes that Murabaha takers will aim to sell the tokens instantly without delay using the same underlying DEX aggregator (ie, Paraswap). Takers can always wait for better on-chain price/liquidity dynamics before executing the second swap, albeit bearing the risk of a worse price/liquidity.

  1. The Murabaha Aggregator/Order Book then adds on any additional Fees to the DEX Aggregator Quote/Base Debt as follows:

Deferred Payment=DEX Quote×(1+((Murabaha Fee Rate+Protocol fee)×D365)){\small \text{Deferred Payment} = \text{DEX Quote} \times \left(1 + \left( (\text{Murabaha Fee Rate} + \text{Protocol fee}) \times \frac{D}{365} \right)\right)}Deferred Payment=DEX Quote×(1+((Murabaha Fee Rate+Protocol fee)×365D​))

We can break down the Murabaha Transaction as follows:

The Sum Debts Owed to the pool = Deferred Payment

Base Debt to Pool = DEX Quote

Pool Profit = DEX Quote * ( (Murabaha Fee Rate *(D) ) / 365)

AZKA Protocol Profit = DEX Quote * ( (Protocol Fee *(D) ) / 365)

  1. The Murabaha and protocol fees are a compensation for the providing this financing up front for the specified duration. It is possible; that due to the pool already having a high utilisation and/or the impact of the DEX Quote/Base debt on the pools utilisation; the Murabaha fee and Protocol fee is quite high. This coupled with price impact and gas fees might make the Murabaha transaction unfeasible for the taker.

Example: Feasibility of a RAC Transaction

Lets assume a user requires 10,000 USDT in financing. Let us further assume that the user is willing to repay the debt after 180 days and would like the debt to be denominated in USDT. The global price for USDT/UNI is 1 UNI per USDT.

In the AZKA UI the user fills the relevant fields, selects the default slippage tolerance and specifies the RAC to be 10,000 USDT.

The Murabaha Order Book runs the query and identifies that 10,101 UNI tokens should be swapped in order to receive 10,000 USDT. Subsequently a (C) value of 10,204 USDT is identified as the amount of USDT required to source 10,101 UNI tokens. The default slippage (0.5%) is multiplied by 2 and added to the (C) value to generate the DEX Quote/base debt of 10,306.04 USDT.

Lets further assume that the Murabaha Fee rate and protocol fee are 5% and 1% respectively (per annum), and the size of the quote doesn't change the utilisation of the AZKA USDT pool such that these rates are impacted significantly.

The base debt is essentially the DEX Quote and Murabaha Fee's and Protocol Fees are applied using the formula as follows:

Deferred Payment = 10,306.04 USDT * (1 + ( (0.05 + 0.01 ) * (180/365) ) )

Deferred Payment = 10,306.04 USDT * (1 + ( (0.06 * 0.493 ) )

Deferred Payment = 10,306.04 USDT * 1.029589

Therefore the Deferred Payment is equal to 10,610.98 USDT.

The user would need to pay this amount no later than the 180 day expiration date.

Lets assume this was a Ethereum based transaction that would incur a gas fee of $50 or 50 USDT in ETH terms for each of the two transactions (total of $100). The true gas adjusted cost of this debt would be 10,710.98 USDT.

What does this tell us?

Well it basically tells us that if we want to receive finance in some amount of UNI tokens which; when sold on-chain for USDT; would result in the user receiving 10,000 USDT and incurring a debt of 10,610.98 USDT to the AZKA USDT pool. The true gas adjusted cost of this debt is 10,710.98 USDT.

If the user is happy with these parameters, they can execute the transaction and expect to receive no less than 10,151.5 UNI tokens in the first swap. As the maximum amount of slippage that can be incurred in the first transaction is 0.5%. If slippage is not incurred on the first transaction, they can expect to receive 10,202 UNI tokens. The subsequent transaction may or may not incur slippage. If the slippage tolerance is not enough to absorb a severe broad market movement then the transaction could revert and still cost the user 50$ for broadcasting either of the transactions.

If the user receives 10,151.5 UNI tokens. When they execute the second transaction and under the assumption that liquidity returns to its original state, if slippage is experienced again, the user can expect to receive 10,000 USDT. Based on the global market price of USDT/UNI, the user was able to obtain financing of 10,000 USDT for approximately 7.1% ( 10,710.98 - 10,000 = 710.98 USDT ) more than the market value of the tokens received and sold.

If the user receives 10,202 UNI tokens. When they execute the second transaction and under the assumption that liquidity returns to its original state, if slippage is experienced, the user can expect to receive 10,050 USDT. Based on the global market price of USDT/UNI, the user was able to obtain financing of 10,000 USDT for approximately 6.6% ( 10,710.98 - 10,050 = 660.90 USDT ) more than the market value of the tokens received and sold.

There are 2 more combinations of what could happen if slippage is or isn't experienced, all of which would result in the true cost of the debt ranging between 6.1% - 7.1% more than the market value of the tokens received and sold.

It is important to re-iterate that a price impact can have a significant effect on the true cost of the debt in comparison to the market value of the tokens received and sold.

PreviousAmount of Murabaha Token Required (AMTR)NextShariah Considerations

Last updated 1 year ago