Adaptive vAMM
vAMM has been a pathbreaking innovation because it provides a counterparty for each trade while abstracting away real assets from price discovery. Following the vanilla vAMM model makes us more scalable as we aren’t dependent on liquidity providers to scale. For example, to list a new asset we just need a constant and reliable price feed and we’re done.
However, there are a few hard problems we must address, which were faced by other perpetual swap protocols functioning on a similar structure: long/short skew, and optimal slippage. Following extensive research, we have decided to model our approach on the vAMM model pioneered by Perpetual Protocol v1 and Drift Protocol.
As a perpetual swap platform, we have two major responsibilities that we need to optimize:
- 1.The market price on Ariel should follow the oracle price as closely as possible:
Funding Rate is the primary mechanism used to balance prices. However, there are certain scenarios that cause the funding rate to have serious issues that could drain the Insurance Fund and result in systemic instability.
The design of vAMM dictates that vAMM is the counterparty for each trade. As a result, a small long/short imbalance is expected. However, if the prices have moved far above/below the price at which the vAMM was initialized, the vAMM can encounter significant long/short skew. An example: Imagine Luna was $40 when vAMM was initialized and now it is trading at $120. In this case, the vAMM would require large long positions to keep the market price close to the oracle price. Due to volatility, if funding goes negative then likely will not be many shorts to pay the funding fee and thus creating a negative feedback loop.
2. Traders should get optimal execution on their transactions:
Having optimal virtual liquidity is the key to achieving better execution price/slippage for the traders. When the market price has moved significantly from the vAMM initialization price, trades start to occur toward the outer end of the constant product curve. This leads to high slippage due to low liquidity.
There are two ways we plan to solve the above problems and make the exchange more robust and efficient:
Repegging is a process by which the terminal price (i.e. vAMM initialization price) is moved closer to the oracle price. This also ensures trading happens using the most liquid part of the curve i.e. center of the curve. Now, in the above-mentioned scenario, we don’t need as many longs if prices have moved up. This also keeps the funding rate in check and the insurance fund is protected. This is done by updating the quote asset (UST) reserves in the pool.
K can be regarded as the virtual liquidity in the pool at any price point. the higher the value of K, the lower the slippage would be for the traders. Intuitively, you would think that having a very large K value would be a logical solution. However, that’s not the case. A higher K value would mean arbitragers need higher capital to bring prices closer to the oracle price. If arbitragers are unable to do so, it would result in a high funding rate and it’s a slippery slope.
Adjusting K is akin to adding/removing the base and quote asset reserves in the vAMM pool. This is dynamically adjusted based on the trading demand on the pool.
Of course, updating quote reserves or updating K when positions are open in the system will not come without cost. This cost would be paid in the form of rebates to the traders who are impacted by it. This will be paid from the Trading Fee Pool. The calculations regarding this will be provided soon.
In the traditional order-book style exchanges, the spread is extracted by the market makers. In our Adaptive vAMM, this value accrues to the pool and is used to make the platform more efficient and secure with Terminal Price repegging and K recalibration. This is a positive feedback loop where the trading fee improves the user’s trading experience by incentivizing long-term growth in volume and reducing long-short imbalance.