In the second article of this three-part series, we described the process of simulating traders’ activity and the principles of work behind the VMM (volatility mitigation mechanism). Please go over these articles first to give you a better context of what we are about to discuss:
AMM Simulation Explained
This article presents some of the insights obtained through simulations that presented different possible market behaviors, covered the trade-offs between pools with different reserve levels, and dived deeper into the work of the volatility mitigation mechanism.
After estimating the parameters for the trade-size distribution, there were several ways proposed to generalize them. The idea behind generalization was to select several cases, which would reflect the main patterns in choosing the size of the swap, and use them inside the simulations.
Below are the generalized parameters for one of the reserve ranges (of stablecoin):
Let’s start with the base case, when the distributions responsible for generating the transactions for each side are the same (traders exchanging each token from the pool behave similarly). It corresponds to a normal situation on the market, when there is no increased demand for one of the tokens.
For each considered reserve range, the initial liquidity for both tokens during the simulation is set to the half of the range based on which the trade-size distribution parameters have been estimated. Tests were conducted for all analyzed reserve values, but the simulations presented below reflect the set up with $75,000 initial liquidity of the stablecoin (Y) and the same amount of tokens for the security token (X).
At the end, the differences obtained for simulations conducted with the remaining initial reserve values are presented. The average frequency of swaps for each side was set to two swaps per hour and the simulations were conducted in two regimes – with the volatility mitigation mechanism disabled and enabled.
The proposed model of parameter generalization allows us to analyze many possible scenarios at once. Particularly, the plot in the top-left corner corresponds to the situation when traders perform mostly small trades.
The plot from the bottom-right corner models a tendency of performing more medium and large size transactions. Each plot from the figure above contains the histogram of generated swap values, applied for a separate simulation.
In the remaining figures, the relative order of inner plots is the same, to preserve the correspondence between the transaction sizes and simulation results.
Figure 3. Variation of Price X Over Time, Initial Reserves for Stablecoin – 30,000 (with VMM Disabled/Enabled)
As mentioned previously, the plot in the top-left corner corresponds to the situation when most of the trades performed were small, resulting in a much more smooth price variation over time.
The plots from the bottom-right corners model a tendency of performing more medium and large size transactions inside the pool, causing a much bigger amount of blocks (the percentage of blocked swaps by the volatility mitigation mechanism is indicated above each plot). It’s visible that the volatility mitigation mechanism blocks the transactions that lead to extreme price changes, reducing the overall fluctuations and keeping the price more stable.
Below are the price impact after each transaction, computed as the percentage difference of the market price before and after the execution of the swap.
The transactions with the biggest price impact were automatically blocked. They cause a sudden change in price and present a serious danger to the stability of the pools with non-traded securities. The price impact is dependent on the amount of swapped tokens relative to the reserves of the pools.
A bigger transaction will lead to a higher price impact, meaning that mostly only large swaps are affected. To illustrate the point, the diagram below presents the success ratio of executed swaps, depending on their size.
Notice how after a certain threshold, the proportion of successful transactions starts to drop. If for transactions smaller than $10,000 in value, the acceptance rate is almost always 100%, only half of transactions near $15,000 in value were accepted. Our previous article highlighted the limitations in the transaction size imposed by the volatility mitigation mechanism.
Depending on the reserves of the pools and the time-weighted average price, swaps bigger than a certain value may be not allowed. The imposed constraints serve to stabilize the price in periods of extremely high volatility and protect the pool from manipulatory transactions.
Dynamic Simulations
In order to present more complex possible market behaviors, it’s necessary to vary the parameters for generating the transactions during the simulation. The detailed process of designing and implementing the logic for dynamic simulations can be found inside the project repository.
First, let’s model a continuous increase in demand for one of the tokens followed by a sudden drop. It corresponds to a ‘pump and dump’ scheme and can be simulated by varying the size and the frequency of generated transactions.
Below is the variation of price obtained during simulations with each of the generalized trade-size distribution parameters.
Remember that the plots from the top-left corner, correspond to the situations when the majority of the swaps are small. In such scenarios, there is no need for the volatility mitigation mechanism to interfere. For the remaining cases, a significantly bigger price variation is specific. Let’s zoom into one of such plots and analyze it in more detail.
Figure 7. Price Variation During Dynamic Simulation (‘Pump and Dump’). Initial Reserves = 75,000 (stablecoin)
Even though the initial price increase is significant (an almost 6x increase), it occurred gradually during the period of several days. As a result, the time-weighted average price is able to catch up with the current price, and the transactions are accepted by the VMM (volatility mitigation mechanism).
However, during the subsequent ‘dump’, which occurred much faster, the VMM kicks in by creating a ‘tunnel’ which dictates the maximum allowed price deviations.
Going Extreme: How Many Tokens Can You Withdraw
This part explores what happens if someone would try to extract almost all of the stablecoins from the pool with enabled VMM and how fast the price can change given the size of the executed trades is below the maximal allowed threshold.
To show the proposed situation, the initial reserves of the pool were set at 75,000 tokens for each side. During the first 24 hours of the simulation, the executed trades were extremely slow in order to populate the oracle with price observations and at the same time, the reserves don’t deviate significantly from the initial values.
After that, a series of max-size allowed transactions were executed, with an interval of 30 seconds. The size for each transaction was estimated in such a way that it wouldn’t be blocked by the VMM and be as large as possible.
The diagram above shows the plot which presents how much reserves have been sliced by each swap (slice_factor), the percentage difference of the amount received tokens, and the amount you would receive by converting the swapped tokens using the time-weighted price (out_amount_diff).
The sequence of maximum-size allowed transactions lie along the separation border. With each next transaction, the out_amount_diff increases and the slice_factor decreases.
During the first six swaps, by depositing 54,678 security tokens (X) into the pool, 31,376 stable tokens (Y) have been withdrawn. The proportion of extracted tokens is about 42% from the initial reserve values. As a result, the price of the security dropped from $1 to $0.33.
The consecutive swaps have the minimum possible transaction value (1e-18) and the estimated out amount for them is zero. Subsequently, TWAP catches up with the new market price and already bigger transactions are allowed to pass.
After the initial big withdrawal caused by the first six transactions, the variation of reserves starts to form a ladder, with one step being equal to the one-hour period. It corresponds to the period-size parameter of the TWAP sliding-window oracle.
By executing continuously maximum-size allowed transactions, the price increased 100x times during the period of two days, so despite the limitations in price variation imposed by the VMM, it is quite robust to faster-moving markets.
Nevertheless, in case of applying the volatility mitigation mechanism for meme token or NFT pools traded on other platforms, where the price can vary basically by more than five times in a matter of a single hour, the prices may be slower to adapt.
As an example, the following limits were obtained during the simulations for maximum allowed price increase in a specific time period (considering the price was stable 24 hours beforehand):
✅ 3x Price Increase - Instantly
✅ 4x Price Increase - 9-Hour Period
✅ 14x Price Increase - 24-Hour Period
How Liquidity Impacts the State of the Pool
Pools with higher reserves are always more attractive for traders, which is not always the case for liquidity providers as with increased liquidity and the same level of activity, the interest rates go down. However, from the perspective of pool stability, especially for tokens not traded on other platforms, a higher liquidity is always preferable.
The proposed method of estimating parameters for the trade-size distribution showed that there is a positive correlation between the size of the swap and pool reserves. It happens because in high-liquidity pools, traders are able to perform the transactions experiencing a smaller price impact.
This also leads to a decreased activity in pools with low liquidity, as traders willing to perform only large swaps are discouraged from using such pools. The analysis of Uniswap v2 pools presented in one of the previous articles also showed that there are almost no existing pools with a high number of transactions and low liquidity.
The variation of price is another important factor to consider. As the price of tokens inside the pool changes after each trade and is determined by the updated balance of the reserves, it is much harder to shift the price in pools with high liquidity.
For pools with tokens having an external market, any significant price difference which may be caused as a result of executed swaps is being instantly arbitraged. In other cases, the volatility mitigation mechanism serves to stabilize the price. Nevertheless, it only intervenes in critical situations, and overall, the price fluctuations in low liquidity pools are much higher (in case trades are big).
Figure 11. Comparison of Price Variation for Distinct Initial Reserve Values. First Case: mostly small trades are drawn from distributions. Second Case: medium and big trades are dominant.
The diagram above shows the comparison of price variation over time in pools with two distinct initial reserves values for stablecoin – $30,000 and $300,000. In each case, the trades are drawn from the distributions with the estimated parameters based on the corresponding reserve ranges.
To generate transactions in a similar pattern but drawn from distinct distributions, for both cases, the size of each swap was derived from a single randomly generated cumulative probability using percent point function.
A higher price variation also causes a bigger number of transactions to be rejected in high activity pools, because of exceeded slippage. It happens when someone else’s transaction is executed before yours, and the difference in price caused by it exceeds the maximal set threshold. As a result, in low liquidity pools, a higher slippage parameter should be set, but this causes these transactions to be more susceptible to MEV-attacks.
During the simulations conducted with small initial liquidity, in some of the cases, the divergence of reserves occurred in the mode with the VMM enabled and when most of the generated trades were big (e.g.: last column, first and third rows).
The divergence happened as a result of the blockage of large transactions after an initial decrease in reserves (caused by the randomly generated swaps). The blockage leads to an even bigger decrease, creating a snowball effect and only accelerating the rate of divergence. The divergence doesn’t happen when the executed trades are small (e.g. first column) and similarly, it would be avoided if the traders would execute a smaller swap, in case their initial transaction was blocked.
Finally, it was briefly mentioned about the threshold for the size of the swap, exceeding which the ratio of success for transactions starts to suddenly drop. This number is much bigger for high-liquid pools and depends also on the stability of the market (for faster moving markets ,it’s lower).
The previous article covered in details what is the maximal acceptable transaction size, given the pool reserves and the deviation of TWAP from the spot price, but based on the conducted simulations, overall, the probability of success decreases significantly after exceeding the following limits:
