Executing Murabaha

A description of how 'Murabaha taker's can execute Murabaha

Satisfy Murabaha Requirements

The max DTC (Debt to collateral) is the maximum value of debt to collateral value that is allowed. For example if the users collateral is worth 10,000$, a max DTC of 75% would assume that the maximum allowed debt in USD value is 7,500$. It is always better to keep a low DTC in order to avoid liquidation. DTC's close to the Max DTC have a higher risk of liquidation. For users with existing collateral and/or debts, they can top up more collateral to maintain the health of their debt or remove collateral as long as they don't fall below the collateral requirement. The users DTC will be displayed before execution.

The Murabaha Amount must also not be less than the 'Minimum Murabaha Amount' and greater than the 'Maximum Murabaha Amount'. Both are risk parameters set governance.

Murabaha Takers can execute up to (x) number of Murabaha's as long as the sum value of their debts is within the collateral requirements.

Upon execution; if the 'Taker' meets the dLP eligibility requirement; they start to accrue vAZKA rewards. Users with already existing debts can initiate a dLP position upon which vAZKA rewards will be activated until debts are repaid or they loose eligibility. (see dLP section in AZKA token design ).

Configure Duration and Amount

AZKA has a max duration framework that is based on the impact of the Murabaha request on the pools utilisation and the average duration of all debts owed to the pool. It may be such that for the requested Murabaha amount, the maximum available debt duration is less than the duration selected by the user. The UI will display the Maximum available duration for the specific amount being requested. Users can configure the amount to obtain new max durations.

Retrieve Deferred Payment Parameters

The AZKA protocol will calculate the amount of currency token (Base Debt) needed to facilitate the users transactional specification and apply Murabaha Fee's and Protocol Fee's to derive the Deferred Payment that must be payed no later than the Expiration Date derived from the selected duration. The deferred payment is essentially the amount that needs to be repaid and consists of : Base Debt + Fees. It is important to note that the base debt is derived by accounting for external market dynamics such as price impact/slippage/swap fees. It may be the case that the size of the Murabaha compared to on-chain liquidity results in an unfeasible base debt value due to price impact. The true cost of Murabaha is a function of all these variables as well as the Gas Fees needed to execute transactions.

Understanding the Murabaha Fee Rate Curve

It is also important to note that the Murabaha Fee Rate/Protocol fee is essentially a curve that is a function of the currency pool's utilisation/available liquidity. As more liquidity from the underlying currency pool is used up to facilitate Murabaha, the Fee increases. The impact of the taker's Murabaha on available liquidity/utilisation will ultimately determine the Murabaha Fee/Protocol Fee they incur.

The Murabaha Fee Rate curve is calculated based on an annual rate and will be standardised to the duration selected by the taker. (ie, assuming the size of a Murabaha has little impact on the Murabaha Fee Rate and the annual rate displayed is 12%, then a Murabaha with a duration of 30 days would incur a Murabaha Fee off approximately 1%.

Post Execution Scenarios

Upon execution it is important that Murabaha Takers are aware of potential slippage due to on-chain dynamics (liquidity constraints/MEV). If the slippage tolerance is not enough to cover the potential price changes between the time the transaction was submitted and when it gets added to the block, the transaction could revert and the user could still incur some gas. If the slippage tolerance is set too high the transaction could be vulnerable to a sandwich attack resulting in the slippage being realised. To manage user expectations, we over estimate the cost of facilitating the Murabaha transactions by including the slippage in the quote price such that; if the slippage is not realised; the user could receive more than the quote, but not less. Azka has a default slippage tolerance of 0.5%. In most cases this slippage wont be realised and the Murabaha taker will usually end up with 0.5% more Murabaha tokens than quoted. However, in scenarios where there are broad market movements during the transaction window, it is possible that this slippage is incurred and the user receives exactly what was quoted by the interface. In the most unlikely scenario where there are substantial broad market movements, the default slippage may not be enough to cover the difference and the transaction could revert and still incur a gas fee for the user. It is impossible to forecast what will happen in advance and it is the users responsibility to set a slippage tolerance they are comfortable with.

Receive Murabaha Tokens

Upon successful execution the user will receive the Murabaha tokens in their wallet. If they intend to sell the Murabaha Tokens, they can proceed by doing so using the same on-chain DEX aggregator, a separate on-chain source or a off-chain source (CEX). All parameters relating to the users debts and other metrics (ie Debt to Collateral Ratio) can be viewed in the portfolio section.