# Uniswap v2 whitepaper: how is formula for "total fees computed since last time fees were collected" derived?

This above screenshot come from uniswap v2 white paper page5 , how is this equation derived ?

(To make the question more searchable, here is the quote in text form)

The total collected fees can be computed by measuring the growth in square root of k (that is square root of x * y) since the last time fees were collected. This formula gives you the accumulated fees between t₁ and t₂ as a percentage of the liquidity in the pool at t₂:

k1 is `k` at `t1`, k2 @ t2.

square root of k1 is size of the pool at the time the user last collected fees.

square root of k2 is the size of the pool now.

dividing one by the other gives you the percent growth.

1 - the percent growth just inverts it.

So:

if

``````// @t1
x1 = 5    // (5 ABC tokens in pool)
y1 = 5    // (5 XYZ tokens in pool)
k1 = x1 * y1 // (so, 25)

// @t2
x2 = 20
y2 = 20
k2 = x2 * y2 // (so, 400)

sqrk1 = sqrt(k1) == 5
sqrk2 = sqrt(k2) == 20

sqrk1 / sqrk2 == .25

// f1,2 ==
1 - .25 == .75 == 75%
``````

So, accumulated fees (that is, your gain as a liquidity provider) as a percentage of the liquidity in the pool at t2 is 75%, because

• the original sqrt of k was 5
• the final sqrt of k is 20,
• 5 is 25% of 20
• so 5 -> 20 is a 75% increase

So if you put in 5 ABC and 5 XYZ @ t1, and later you go pull out 20 ABC and 20 XYZ @ t2, you gained 75% in fees from t1 to t2.

(It's "in fees" because that's what causes the rise in your portion of the pool size; other users adding to the pool is not relevant / accounted for here. Assume these x & y & k values are liquidity-provider-specific, or in this case, that 1 liquidity provider has provided all the x & y @ t1, and that the increases in x & y @ t2 have all come from the fees gained from swaps, while the new ratio reflects the collective outcome of arbitrage performed.)

Conveniently, we can also see that we put in 10 tokens, and got out 40 tokens, and 5 -> 40 is a 75% increase. So, why this equation with `k` and a `square root`? Well, in our example above, x and y have identical value--they trade at 1:1 at the start and the end. Within that equation, that lets us basically treat them as apples:apples--that's unusual, though, and almost never the case in the real world.

What's interesting is to compare this scenario with another scenario, where `x2 = 10` & `y2 = 40`. In this scenario, `k` would be the same.

In that case, we put in 10 tokens, and get out 50 tokens, and 10 -> 50 is an 80% gain. Yet `k` of `(x=20 * y=20)` is the same as `(x=10 * y=40)` So is our increase actually 75%, or 80%?

That's part of why `k` is such a cool unit, and why this equation using k exists. It's capturing the underlying changes in the token values themselves very elegantly. We now have more y, but the value of y has gone down. We increased less in x, but the value of x has gone up. Through k, we use x and y as relative indicators of value to each other.

@Kyle Baker's answer explained this very well. I would like to explain further the cases where the price of the 2 tokens change. And this involves the impermanent loss.

1. First, let's consider the case that no fees at all:

For simplicity, let's assume you have all the portions in this pool and the pool starts with:

``````x1 = 5    // (5 ETH in the pool)
y1 = 5    // (5 DAI in the pool)
k1 = x1 * y1 // (so, 25)
Eth price: DAI price = 1:1
So your tokens are worth: 10 DAI (1 ETH = 1 DAI)
``````

After some time, the ETH price rises up to 1 ETH = 4 DAI, then the pool ends with:

``````x2 = 2.5 // (10 ETH in the pool)
y2 = 10 // (40 DAI in the pool)
k2 = x2 * y2 // (so, 25)
Eth price: DAI price = 4:1
So your tokens are worth: 4 * 2.5 + 10 = 20 DAI
``````

It seems that you have gained some profit. But is it true? Let's consider that instead of adding your token into the pool in the first place, you just HODL them till now. Then, the total value of your tokens will be:

``````5 ETH * 4 = 20 DAI + 5 DAI = 25 DAI in total
``````

So you have actually lost 5 DAI compared to just HODLing. This is called impermanent loss.

But how is that related to the fee ratio? Let's dig deeper.

1. This time, let's consider the fees.

We start from 5 ETH and 5 DAI again, and after several `swaps`, the pool cumulated fees in its pool and ends with:

``````x2 = 10 // (10 ETH in the pool)
y2 = 40 // (40 DAI in the pool)
k2 = x2 * y2 // (so, 400)
Eth price: DAI price = 4:1
So your tokens are worth: 80 DAI
``````

The fee ratio is still `1 - sqrk1 / sqrk2 == 75%`, meaning 75% of the total value comes from transaction fees. However, if you calculate the left 25% of your total value, it is:

``````80 DAI * 25% = 20 DAI, coming from 25% * 10 = 2.5 ETH and 25% * 40 = 10 DAI
``````

And that is exactly the same as what we've calculated before, assuming no fees at all. I have to say that CPMM is so elegant that by calculating the `1 - sqrk1/sqrk2`, you automatically take the impermanent loss into account. and the ratios give you the exact values coming from transaction fees.