Amplification improves capital efficiency of liquidity pools within KyberSwap. The curves are still a constant product, but with virtual balances instead of real balances. Thanks to the virtual balances, which are amplified significantly from real balances, KyberSwap pools can achieve moderate spread and slippage rates compared to the Uniswap model given the same capital.
Each liquidity pool consists of 2 tokens. We first define and to be the liquidity providers’ initial contributions to the pool, such that . refers to the amount of the first token in the pool. refers to the second token in the pool. This is the familiar simple constant-product function.
Typical Liquidity Pool
As an example, let's say that we have two tokens (Apples and Bananas). A pool can start with an equal number of both tokens. In this instance, we can start with 5000 Apples and 5000 Bananas.
Taking Apples as x, and Bananas as y, 5000 (Apples) * 5000 (Bananas) = 25,000,000 (k). The constant is 25,000,000. Every swap from apples to bananas, or bananas to apples, must result in the Liquidity Pool still having the same constant.
If you want to swap in Apples, you will receive Bananas (Note: you can edit the number of Apples to swap in, and see the numbers change accordingly).
If you put in 1000 Apples, this will increase the number of Apples to 6000.
k must always be 25,000,000. We have to divide 25,000,000 by the new number of 6000 Apples. From there, you get 25,000,000 / 6000 ≈ 4166.67, which is the desired amount of Bananas to maintain constant k.
The current number of Bananas is 5000. To maintain the current constant of k, the number of Bananas has to decrease to 4166.67. Therefore, you will receive ~833.33 Bananas (which is 5000 - 4166.67).
Therefore, you will get ~0.83 Banana for 1 Apple. If you expect 1 Banana for 1 Apple, there is a price impact of about -16.67%.
We now introduce what is known as the amplification factor
a > 1. As its name suggests, it amplifies the real balances to virtual balances. Hence, we can define virtual balances and , where and .
The pool with programmable pricing curve model will maintain a constant product of these virtual balances by using the new inventory function:
The constant can be derived from as follows:
Amplified Liquidity Pool
In this example, we can start with 5000 Apples and 5000 Bananas.
The amplified amount of Apples is: 2,000,000 (5000 Apples * 400 (amplification) = 2,000,000). The amplified amount of Bananas is: 2,000,000 (5000 Bananas * 400 (amplification) = 2,000,000). 2,000,000 (Apples) * 2,000,000 (Bananas) = 4,000,000,000,000 (k) The amplified constant is 4,000,000,000,000.
If you want to swap in Apples, you will receive Bananas.
If you put in 1000 Apples, this will increase the virtual balance of Apples to 2001000.
k must always be 4,000,000,000,000. We have to divide 4,000,000,000,000 by the new number of 2001000 Apples. From there, you get 4,000,000,000,000 / 2001000 ≈ 1999000.50, which is the desired amount of Bananas to maintain constant k.
The current virtual balance of Bananas is 2000000. To maintain the current constant of k, the number of Bananas has to decrease to 1999000.50. Therefore, you will receive ~999.50 (2000000 - 1999000.50).
Therefore, you will get ~1.00 Banana for 1 Apple. If you expect 1 Banana for 1 Apple, there is a price impact of about -0.05%.
We see that users benefit from lower spread and slippage when the pools use the new pricing curve. However, this comes at the expense of the price range no longer being unbounded, but being restricted between a fixed price range.
Let us take a pool with amplifcation factor 2 as an example, where the virtual balances are double the real balances in the original constant-product model. The price range support for this is from to . In other words, this particular pool can support 0.25x to 4x the initial price set. Should this price range be exceeded, it would result in the pool being depleted of one of the tokens.
The inventory curves of Uniswap, Curve and programmable pricing curve are visualized in figure below.
Inventory curves of Uniswap (red), Curve (green) and programmable pricing curve (blue)
Price ranges in the Amplification model
To illustrate mathematically:
- be the price function of against
- Initial price,
- , the minimal and maximal price supported by the programmable pricing curve respectively
Therefore, to compute the minimal and maximal price:
The pool will run out of token or when the real balances and are zero respectively.
In summary, we see that users benefit from lower spread and slippage when the pools use the new pricing curve. However, this comes at the expense of the price range no longer being unbounded, but being restricted between and .
Functions of price ratio (red), 1 (blue), and (black)
Inventory curves of two reserves: Uniswap V2 swap model (green), Amplification model (violet)