This article describes the work of the IX Swap Data Science Team that performs analysis of different AMM pools activity (the market).
Mitigation mechanism is a process that reduces or eliminates long-term risks to people and property from certain dangers, such as extreme price changes that can happen due to the principles of how token prices are estimated using this formula:
Set in the core of an automated market maker or AMM is an enhanced version of this formula, as follows:
where k presents 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 prices distributions from following the external markets and lead to the total elimination of the pool activity due to broken pool parameters.
The AMM Problem: Why Mitigation Is Required
The transaction size can lead to a negative impact on the price distribution and cause great deviation depending on the size of pool reserves. Considering that there are external factors that can cause extreme changes in the token prices, it is required to set an algorithm that can “smooth” the price distribution and make it adaptive to market changes. For example, in the case below, the same transaction is performed on the same pool with different reserves sizes:
The regulation algorithm must adapt in such a manner that the first case could be blocked because of its significant price impact and in the second case transaction would not be blocked considering price distribution before the reviewed one.
Diagram 1: How AMM Supply and Demand Price Regularization Works
Mitigation Mechanism Explained
The first element of the mitigation mechanism is the time-weighted average price (TWAP). This is the price (P) multiplied by how long it lasts (T) and is continuously added to a cumulative value (C). To understand how this works, here’s a step-by-step short example:
- Imagine a pool with a WETH price equal to 3,000 when the timestamp is 0. Therefore, C = 0
- The next price value of WETH goes to 3,200 at the timestamp of 200. Therefore, C = 0 + 3,000 * (200 – 0) = 600,000
- At the timestamp of 250, the WETH price changes to 3,150. C = 600,000 + 3,200 * (250 – 200) = 760,000.
The TWAP in the time interval between 0 and 250 timestamps is:
which corresponds with the price of 3,000 lasting for ⅘ of the time and the price of 3,200 lasting for ⅕ of the time.
So this is the next formula:
The estimated Weighted average price will be a good reference point to estimate acceptable price deviations. Using this price, it is possible to set a deviation threshold and achieve “stabilization” of the price distribution inside the pool.
This ensures a more attractive price distribution for traders, a smaller price deviation window (and therefore, reducing price manipulation window), and the impossibility of destructive actions on the pool (like extraction of tokens out of the pool). Below is a diagram without TWAP price distribution, which means it contains bigger drops and rises of the price distribution.
Diagram 2: Demonstration of How TWAP-Based Price ‘Tunnelling’ Works
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 transaction placed in the estimated “tunnel” – the transaction is executed.
Working Principles Behind Mitigation Mechanism
What is required to be done before a mitigation check?
This is a detailed overview of the transaction verification to check if it matches mitigation requirements, or it should be declined. This 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 the mitigation verification, it is required to perform verification of the reserves (does the pool contain enough reserves of both tokens to execute the transaction or not) and then verify the 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, a mitigation check is performed.
How is the mitigation check performed?
A mitigation mechanism takes a transaction for verification if it successfully passed previous verifications, and the mitigation mechanism work is enabled. The verification of the transaction is based on finding the slice factor of the transaction, which requires the calculation of tokens out values with applied system fees to see how the reserves after will look like after performing the transaction.
After finding a reserve for this token, the mitigation script takes the transaction info and assumes the final reserve in case the mitigation verification for the pool is enabled.
First, the algorithm calculates the slice factor of the change caused by the execution of the transaction using this formula:
and then calculate the slice factor curve using the following formula:
This slice factor curve will estimate the margins (limits) of price distribution (or forms a “tunnel” where transaction should be placed to pass the check, as the principle shown above). In case the curve sets too high margins, it is possible to reduce them to a 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 the out value that should have been placed in case tokens would have been exchanged conform TWAP value:
After the TWAP-estimated out value is calculated, the difference between the transaction-estimated out value of the token and the TWAP-estimated out value of the token is computed using the following formula:
The final check will be compared to the out value difference of the slice factor curve using the next principle:
After these are done, these verifications can estimate if a transaction can pass and be executed or should be declined.
How Mitigation Mechanism Change Pool Distributions
During analysis of the pools, there were tested cases with enabled and disabled mitigation mechanisms. For example, in the case of the WBTC/DAI pool, it can be seen that with the application of the mitigation mechanism, the distribution of WBTC prices greatly stabilized.
Picture 1: WBTC Price Distribution in the WBTC/DAI Pool With Enabled/Disabled 24-Hour Mitigation Mechanism
The distribution shown above demonstrates the result of a mitigation mechanism with a 24-hour window of values (TWAP for the last 24 hours). The modification of this script to take on values with up to 48-hour window, in case the 24-hour window can not be formed, changes the WBTC price distribution as shown below:
Picture 2: WBTC Price Distribution in WBTC/DAI Pool With Enabled/Disabled Up to 48-hour Mitigation Mechanism
The picture above demonstrates that token price distribution greatly changes and distribution is much more stabilized. The mitigation mechanism removes/ignores transactions that have too big an impact on the price distribution that can break pool behaviour.
In the picture below, it can be seen that the mitigation mechanism allowed transactions with a small price impact (“healthy” impact).
Picture 3: Price Change After Each Transaction Distribution With and Without Mitigation Mechanism
On the presented distributions, it can be clearly seen how the use of mitigation mechanisms raises the attractiveness of the pool to traders and reduces possible risks to them.
. . .
About IX Swap
IX Swap is a next-generation platform that leverages DeFi services backed by CeFi regulatory compliance to facilitate safe and convenient issuance, listing, and trading of security tokens and fractionalized NFTs.
By bridging the gap between traditional finance and innovative blockchain-based solutions, IX Swap is paving the way in democratizing access to traditional financial markets that have never been done before.