📈Volatility Mitigation Function ext
Last updated
Last updated
Mitigation mechanism represents a process that reduces/eliminates long-term risks to people and property from some dangers, like extreme price changes that could happen due to the principles of how token prices are estimated conform to the next formula:
And with the enhanced version of this formula set in the core of the AMM:
Where k is presenting a constant balance of assets. This structure leads to the problem of price regulation when big swaps of the tokens are able to cause extreme changes in the token prices and therefore decline pool price distributions from following the external markets and lead to the total elimination of the pool activity due to broken pool parameters.
A transaction size can lead to a negative impact on the price distribution and cause great deviation depends on the size of pool reserves. Considering that there can be some external factors causing extreme changes in token prices it is required to set an algorithm that will be able to “smooth” price distribution and be adaptive to the market changes. For example, in the case below there is the same transaction performed on the same pool with different reserves sizes:
A regulation algorithm must adapt in such a manner that the first case could be blocked because of a big price impact and in the second case transaction would not be blocked considering price distribution before the reviewed one.
The first element of the mitigation mechanism is the time-weighted average price (TWAP). This is a price P multiplied by how long it lasts T is continuously added to a cumulative value C. To understand how it works below is shown step-by-step short example:
Below is presented that without TWAP price distribution would contain more significant drops and rises of the price distribution.
When a person tries to perform a transaction through a pool with an enabled mitigation mechanism, the transaction is verified by the impact on the price distribution, that it will cause on this pool and the acceptable price deviation estimated on top of the TWAP. In case the transaction matches estimated conditions and the transaction is placed in the estimated “tunnel” - the transaction is executed.
Here is a detailed overview of the verification of the transaction to check if it matches mitigation requirements, or if it should be declined. This overview will be based on the mechanisms that were applied for simulations of the trades and the comparison of distributions with and without mitigation mechanisms.
Before mitigation verification, it is required to perform verification of whether the reserves do pool contain enough reserves of both tokens to execute the transaction, or not and then verify slippage of the transaction if one was applied check if the price of token exchange is not too far from the expected by trader value. If both checks are passed, then a mitigation check is performed.
The mitigation mechanism takes transaction for verification if it successfully passed previous verifications and mitigation mechanism work is enabled. Verification of the transaction is based on finding the slice factor of the transaction, which requires a calculation of tokens out values with applied system fees to see how reserves after performing the transaction will look like.
and then calculates a slice factor curve using the formula:
This slice factor curve will estimate margins (limits) of price distribution (or forms a “tunnel” where transaction should be placed to pass the check, the principle is shown above), but in case if curve sets too high margins it is possible to reduce them to smaller window manually (estimated acceptable deviation for pool). After preparing “margins” to perform transaction verification it is required to find how the transaction deviates from the expected distribution. The algorithm calculates out a value that should have been placed in case the tokens would have been exchanged conform TWAP value:
After calculating TWAP-estimated out value, is calculated difference between the transaction-estimated out the value of the token and TWAP-estimated out value of the token:
The final check is in comparison of the found out value difference with the slice factor curve, conform the next principle:
After all, those verifications can be estimated if a transaction can pass and can be executed or should be declined.
During analysis of the pools were tested cases with enabled and disabled mitigation mechanisms. For example, in the case of the WBTC/DAI pool it can be seen that application of the mitigation mechanism distribution of WBTC price will greatly stabilize.
WBTC price distribution in the WBTC/DAI pool with enabled/disabled 24-hour mitigation mechanism.
Shown above distribution demonstrates the result of work for the mitigation mechanism with a 24-hour window of values (TWAP for the last 24 hours). Modification of this script to take on values with up to a 48-hour window in case of a 24-hour window can not be formed changes WBTC price distribution as shown below:
WBTC price distribution in WBTC/DAI pool with enabled/disabled up to 48-hour mitigation mechanism.
The presented picture demonstrates that token price distribution greatly changes and distribution is much more stabilized. The Mitigation mechanism removes/ignores transactions that have a too large impact on the price distribution and that can break pool behavior. In the picture presented below, it can be greatly seen that mitigation passes transactions with a small price impact (“healthy” impact).
Price change after each transaction distribution with and without mitigation mechanism
On the presented distributions can be clearly seen how the use of mitigation mechanisms raises the attractiveness of the pool to traders and reduces possible risks to them.
