Two different methods have been used in order to obtain the potential fee earned on Uniswap v3.
One uses data stored by Uniswap for a given tick. The function - find_fee_from_tick_data and examples are available in entry_point.py.
1. One has to have an Infura and Etherscan accounts. It is necessary to export env variables: export WEB3_INFURA_PROJECT_ID = your_infurs_project_id export ETHERSCAN_TOKEN = your_etherscan_token
2. Brownie can't get the data for every second Uniswap contract. It seems that the ABI is missing as Uniswap uploads the same contract with different fee and omits part of the data. Probably, it can be fixed within brownie if needed.
3. This solution has to find an initialized tick. Thus there is a risk that exotic positions can't be simulated. As the tick fee function will look for closest initialized ticks and they might be not found if initial position is too out of range.
This solution is based on the medium article published by the defi lab. https://defi-lab.medium.com/historical-performances-of-uniswap-l3-pools-2de713f7c70f The function name is find_fee_from_graph_pool_data_defilab.
1. As they point out it is assumed that a position either within or out of a range during an hour. This might introduce a slight error, especially if short lasting positions are considered. This can be improved as one may track current price and when position goes out of range. Once this happens an extra call to graph data can be made.
2. In other articles a correction term is introduced L_position/L_total. This correction term is omitted in https://defi-lab.medium.com/historical-performances-of-uniswap-l3-pools-2de713f7c70f The correction term is needed because when feeGrowthGlobalToken_i is calculated the L_total is used:
feeGrowthGlobalTokenI = feeGrowthGlobalTokenI + fee0/L_total
and L_total is distorted by a liquidity of a position. Thus later on when fee_i_per_hour = feeGrowthGlobalToken_i_per_hour*L_position is calculated one needs to multiply by a correction term :
Correction_term=L_total/(L_total+L_position).
This is assuming that liquidity doesn't change much during the hour.
fee_i_per_hour = feeGrowthGlobalToken_i_per_hour * L_position * Correction_term
1. In Uniswap v3 each user deposits funds which are traded according to it's own curve. These can be 'transformed' to Uniswapv2 curves by representing them with virtual reserves. This kind of representation allows to see why curves can be "summed up" to a global Uniswap v2 curve between two ticks and why liquidities sum up linearly.
2. One can use this article - http://atiselsts.github.io/pdfs/uniswap-v3-liquidity-math.pdf to deduce formulas for token2 quantity given token1 and price ranges. It is interesting to note that equation 10 of this paper can be deduced in a much more simple way. It is enough to use that Y_virtual divided by X_virtual equals the price.