This article introduces how the K value in the constant product algorithm in uniswap is designed.

Let's take a trading pair in uniswap, ETH/USDT, to illustrate how the K value is designed.

Constant product algorithm

When the first person in uniswap adds x ETH and y USDT as liquidity, it determines the initial size of the K value, that is, K=x*y.

At this time, ETH and USDT together constitute a liquidity pool. Please remember this concept, it is very important.

The first person to add liquidity can arbitrarily add the number of two coins in the trading pair, that is, the K value can be arbitrarily determined.

After adding liquidity, the price of ETH is equal to =y (the number of USDT) / x (the number of ETH). If there is a price difference between this price and other exchanges, it will definitely be arbitrage.

The so-called constant product algorithm means that when the liquidity pool does not add or reduce the liquidity, only the transaction behavior occurs, the K value is unchanged.

That is, if the user buys or sells ETH in the ETH/USDT trading pair, the K value cannot be changed.

The trading behavior will modify the composition of ETH and USDT in the liquidity pool. For example, if the user buys dx ETH, the amount of ETH in the liquidity pool becomes (x-dx), and the amount of usdt becomes K/(x-dx), that is, the user needs to spend dy=K /(x-dx)-y Usdt to buy dx ETH.

Transaction fees affect K value

However, due to transaction fees, users need to pay a 0.3% fee when using uniswap transactions. For example, if a user buys ETH with dy usdt, uniswap will first deduct the 0.3% dy handling fee and set aside the 0.3% dy handling fee. After the transaction is completed, the 0.3% dy will be added to the liquidity pool. At this time, the K value becomes x*(y+0.3%dy).

Therefore, the K value of the constant product algorithm is not constant, and every transaction will affect the K value.

Adding liquidity affects K value

If there is xETH/yUSDT in the fund pool now, K=x*y. Now someone has added liquidity, adding dx ETH and dy usdt, and dx/dy=x/y.

If you use Uniswap's default setting, that is, when you add liquidity, first enter the amount of ETH, and then uniswap will calculate how much usdt is required by default. This default calculation is to keep dx/dy=x/y.

However, after adding liquidity, the funds in the liquidity pool become: (x+dx)ETH/(y+dy)USDT. At this time, (x+dx)(y+dy)>xy. Therefore, the added liquidity K value becomes larger.

The same reduction in liquidity will reduce the K value.

Donation affects K value

If you add liquidity instead of adding dx/dy=x/y, you can directly transfer dx>0 and dy=0 to the contract address. This will also change the K value.

Such things often happen. Some people mistakenly transfer ETH to a uniswap liquidity pool contract address, which causes donations and gives the coins to all the original liquidity owners in vain.

This kind of non-K ratio to increase liquidity is called donation by uniswap.

But this kind of donation behavior can be arbitraged by other people in design. For example, if someone recharges dx>0, dy=0; at this time, another person can recharge dy proportional to the value of K, and perform an operation to add liquidity, then they can donate the dx. This is quite complicated, and I don't know the details.

Any liquidity that is not added in proportion to the K value will generate donations. For example, dx/dy>x/y, first add the liquidity of (dx-ddx)/dy=x/y, and return the corresponding amount of LPtoken to the user. Then ddx becomes a donation.

Also, in the same block, there may be transactions that add liquidity, and there are transactions that are buying and selling, and the K value will change more complicatedly.