Skip to main content
Version: V2

Amplification

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 x0x_0 and y0y_0 to be the liquidity providers’ initial contributions to the pool, such that x0y0=kx_0 \cdot y_0 = k. x0x_0 refers to the amount of the first token in the pool. y0y_0 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%.

Amplification Factor

We now introduce what is known as the amplification factor a and a > 1. As its name suggests, it amplifies the real balances to virtual balances. Hence, we can define virtual balances x0x'_0 and y0y'_0, where x0=x0ax'_0 = x_0 \cdot a and y0=y0ay'_0 = y_0 \cdot a.

The pool with programmable pricing curve model will maintain a constant product of these virtual balances by using the new inventory function:

xy=kx' · y' = k'

The constant kk' can be derived from kk as follows:

xy=kx0y0=k(x0a)(y0a)=kk=ka2xy=ka2x' \cdot y' = k' \\ x'_0 \cdot y'_0 = k' \\ (x_0 \cdot a) \cdot (y_0 \cdot a) = k' \\ k' = k \cdot a^2 \\ x' \cdot y' = k \cdot a^2

Amplified Liquidity Pool

In this example, we can start with 5000 Apples and 5000 Bananas.

Amplification:

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%.

Inventory Curves

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 P04\cfrac{P_0}{4} to 4P04P_0. 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 curve comparison

Inventory curves of Uniswap (red), Curve (green) and programmable pricing curve (blue)

Price ranges in the Amplification model

To illustrate mathematically:

Let

  • PP be the price function of XX against YY
  • Initial price, P0=y0x0P_0 = \cfrac{y_0}{x_0}
  • Pmin,PmaxP_{min}, P_{max}, the minimal and maximal price supported by the programmable pricing curve respectively

Therefore, to compute the minimal and maximal price:

Pmax=P0(aa1)2Pmin=P0(a1a)2P_{max} = P_0 \cdot (\cfrac{a}{a-1})^2 \\ P_{min} = P_0 \cdot (\cfrac{a-1}{a})^2

The pool will run out of token XX or YY when the real balances x0x_0 and y0y_0 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 PminP_{min} and PmaxP_{max}.

Functions of price ratios

Functions of price ratio PminP_{min} (red), 1 (blue), and PmaxP_{max} (black)

Inventory curves of two reserves

Inventory curves of two reserves: Uniswap V2 swap model (green), Amplification model (violet)