The constant product K value in Uniswap will be affected by transaction fees, added liquidity and donation behavior.
Original Title: “K Value in Uniswap’s Constant Product Algorithm”
Written by: Huang Shiliang
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 added x ETH and y USDT as liquidity, it determined the initial size of the K value, that is, K=x*y.
At this time, ETH and USDT together form 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 refers to the fact that when the liquidity pool does not add or reduce 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 a user buys dx ETH, the amount of ETH in the liquidity pool will become (x-dx), and the amount of usdt will become 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 trading with Uniswap. 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 value of K 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)>x*y. 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 add liquidity is called donation by Uniswap.
But this kind of donation behavior can be arbitrage by other people in design. For example, if someone recharges dx>0, dy=0; at this time, another person can recharge dy in proportion to the K value and perform an operation to add liquidity, then the donation of dx can be donated. 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 (dx-ddx)/dy=x/y liquidity, 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, or transactions that are buying and selling, and the K value will change more complicatedly.
Thanks to Plancker Dao member Li Shisheng for his contribution to this article.
