# Fee calculation vs invariant in Uniswap V3

In v3, fee tokens are held/tracked separately from the liquidity pool. This means that, unlike in v2, the invariant product does not change after a trade, as we see below.

Consider a specific pool with a given range-position, and suppose it has _virtual_ reserves $x,y$ corresponding to assets X, Y respectively. Suppose these reserves initially satisfy the product-invariant $xy=L^2$. When a trader wants to put in $\Delta x$ amount of X tokens and receive $\Delta y$ Y tokens in exchange, here is how we can calculate $\Delta y$ they will receive, taking fees into account. Suppose the fee rate is $1 - \gamma$, e.g. $1 - \gamma = 0.003$.

1. *Reduce* the amount of X tokens converted, by the fee, so effectively they will convert $\gamma \Delta x$ of X
2. Plug this reduced amount into the invariant formula to get the corresponding $\Delta y$:
$$ (x + \gamma \Delta x)(y - \Delta y) = L^2 $$
3. Track the fee paid as $(1-\gamma)\Delta x$ amount of X tokens

Note that due to the non-fungibility of liquidity pools in v3, the fees are kept separate from the pool. Here are some relevant highlights from the v3 whitepaper:


As a consequence,

>the exact same invariant continues to hold for the virtual reserves in a given liquidity pool.

This is in contrast to v2, where the $(1-\gamma)\Delta x$ is added back to the X reserves, so the new level of X tokens is $x + \gamma \Delta x + (1 - \gamma)\Delta x = x + \Delta x$. But since $\Delta y$ was calculated to satisfy the above equation, the new product of reserves $(x + \Delta x) (y - \Delta y)$ will *exceed* $L^2$ slightly. This is in fact what the v1 whitepaper says (the fee mechanism is identical to v2):