All Your Uniswap v3 Liquidity Farming Calculations Are Dead Wrong! Here’s Why – Cryptopolitan

Home » News » DeFi News
2 x 2 = 5
You know it’s wrong, but when you first see it, you second-guess yourself and think: “Maybe something’s wrong with my calculation”. Right?
Well, that’s exactly how I felt when I discovered that the liquidity and TVL (Total Value Locked) figures displayed on the Uniswap V3 user interface were completely wrong.
Uniswap is the biggest decentralized finance (DeFi) project on Ethereum and the whole blockchain industry. Thousands of liquidity providers use these figures daily to build their investing strategies. So how could these figures possibly be inaccurate?
I have spent hours trying to find a mistake in my calculations, and guess what? I didn’t make any mistakes. And the situation is even worse than just inaccurate TVL.
But let’s go step by step and start with the problem.
Firstly, what is TVL, and how is it used? In short, TVL is defined as a dollar value of all crypto assets currently delegated by users to a blockchain or protocol. For example, these assets may be the total liquidity of a decentralized exchange, bridge or lending protocol, or total staked assets of PoS blockchain.
Crypto market investors and other participants use TVL for multiple cases:
Looks like it’s important to know accurate TVL numbers, right?
But what if I say that the most available data about Uniswap v3 TVL is misleading? The biggest surprise for me, though, was that the official Uniswap Chart App is also a problem! Here’s how I found out.
I was working on a liquidity analytics project, comparing official data on Uniswap v3 with my calculations using raw blockchain data. This step is vital to comply with the highest data quality standards. To begin verification, I chose a popular liquidity pool, USDC-WETH (0,3% fee level).
Look at pool 3 on Uniswap v3—it has an impressive TVL of $333m (based on Uniswap official charts at the time of writing) and a healthy daily volume of $61m.
Immediately I ran into a problem: my calculated TVL value was $176m instead of the $333m reported on the Uniswap website. Ok, so bugs happen. But before jumping to debugging, I decided to verify the TVL on the most popular Ethereum blockchain explorer, Etherscan. Technically, each Uniswap v3 pool is a smart contract. So, the blockchain explorer can show the token balances in the pool’s possession, which is what TVL is.
I expected the token balance of the pool to be a bit larger than the TVL reported by Uniswap. That’s because the pool holds liquidity as well as fees that have been accrued but not yet claimed. But this balance was almost half the amount Uniswap reported, and, surprisingly, it was the same figure as my calculations!
Comparing the liquidity, asset by asset, also showed a huge difference. At this point, I realized the error had nothing to do with my math skills.
But how could this happen? After researching, I found that Uniswap relies on the decentralized blockchain indexing service The Graph. With this service, any developer can add a personal analytics code (called subgraph) for specific blockchain data use cases and make the analytics available through API.
Uniswap Labs has created its own subgraphs for Uniswap protocol analytics and made them available through The Graph Hosted Service. The good thing is that its code is publicly available. The bad thing, though, is its TVL calculation errors.
A brief analysis of the code shows that it accounts for all swaps and liquidity events but doesn’t account for fees. Uniswap pools have a 0.01% to 1% fee on every swap. This fee is deducted from traded assets and accrued to liquidity providers. In turn, liquidity providers can collect accrued fees at any time.
The current Uniswap v3 subgraph, though, displays the figures as if no fees were ever accrued and collected. So, the Uniswap v3 TVL figures deviated from reality with each swap.
You may wonder: “Did you submit an issue ticket on GitHub before writing this article?” Yes, that’s my first intention after discovering the error. And you know what? That issue is already logged, created by a core developer in November 2021!
So why wasn’t this problem fixed? I have no idea. Maybe the error was negligible at the time this bug was discovered. However, this is a cumulative error that grows with each swap. So, as the fee and trading volume in the pool grow, the resulting TVL discrepancy from the error will result in a larger difference from reality. And we can see that in a big pool like USDC-ETH with a larger 0.3% fee—it’s become out of control! It’s currently almost double the true figures.
Ok, we know by now that the TVL numbers in individual pools are distorted. We’ll explore how this can affect investment decisions below. But before we get to that, let’s see how these errors affect the total TVL of Uniswap v3’s protocol. This TVL is reported at almost $12b at the time of writing.
You don’t have to be a data scientist to see something is wrong here.
We can see above that TVL was reported as slowly but steadily growing from $500m to $4.5b on March 6th, 2022. Then something crazy happened, and TVL was reported as $254b on March 7th, 2022. That’s 2,5x more than the highest TVL of the whole Ethereum network ever—in ONE day! Clearly, it’s a mistake in the data. In the following weeks, the TVL was reported as $10-20b.
At this point, I lost all trust in Uniswap analytics data. But how can we know the true TVL? I had 2 options.
Option 1—fork out and fix the Uniswap v3 subgraph. The bad thing about this option is that it would take days for the subgraph to reindex. And I’m not a fan of the GraphQL language The Graph uses.
Luckily, I had option 2— – Datamint’s high-performance analytical databases for all Uniswap v3 and Ethereum data, readily available for complex online queries.
After some experiments, I’ve created the following algorithm for accurate TVL calculation. Check the step-by-step process below.
After multiple cross-checks, I came up with a TVL calculation. I started it and wanted to get coffee while the calculation was executed, but it finished before I stood up. This is the only downside to using a high-performance analytical database.
Are you ready to see the result?
It’s almost 4 times less than the reported $11,8b… It’s up to you to draw a conclusion.
Disclaimer: My calculation may contain errors. In data projects for enterprise clients, we use documented methodology, autotests, and many other tools to achieve the highest data quality. These tools would be overkill for a personal research project like this. This research highlights the obvious problems in available data rather than providing a final solution.
The problem isn’t incorrect numbers but rather the decisions we make based on those numbers. For example, most profit calculators for liquidity providers use these numbers for predictions.
However, it isn’t that difficult to fix the TVL calculation. Either Uniswap Labs fixes it in their subgraph code, or calculator developers start using other data sources. The core question is whether we can be confident that calculator predictions are correct.
I did some calculations, and the short answer is—not even close.
A bold claim, I know. Many liquidity providers use existing calculators and affect decisions that cost tens of millions of dollars. But let’s go through the calculation steps so you can make your own judgment.
First, let’s review some core concepts of the Uniswap v3 protocol.
One of its main innovations is concentrated liquidity. In essence, with Uniswap v3, you can select the price range you want your money to work as a liquidity provider. This is an amazing concept that can bring great value to protocol users. Liquidity providers limit their exposure to impermanent loss, and traders can enjoy smaller price slippage when volatility is low. But all these potential benefits come at a costcomplexity.
So, we want to understand how the earnings of the Uniswap v3 liquidity provider are calculated.
In Uniswap v3, the liquidity provider selects the price range to provide liquidity to. He’ll get his cut of the swap fees once the price is inside this range. At first glance, a liquidity provider wants to have the price range of his liquidity position as wide as possible. However, the liquidity is distributed proportionally over this range. So, the wider the range, the lower the swap fee is for each deal.
In this example, option A shows the liquidity provider choosing a wider price range, and option 2 shows a narrower one with the same amount. Provided that, in both cases, the price is inside the chosen price range, the liquidity provider gets 3x more fees in option B. However, if the price is more volatile, the liquidity provider might end up with a higher profit in option A.
So, in reality, selecting the right price range relies on finding the best balance between the risk of missing the price and receiving a lower return on each deal.
One more parameter influences the profit of the liquidity provider and is often overlooked. I’m not aware of any LP profit calculator that considers it, and this parameter can change everything. You’re wondering what this is by now. It’s the distribution of the LPs. Consider the following example:
In this example, two liquidity providers (LP1 and LP2) have positions. LP1 has a narrow position of $3. LP2 has a wide position of $5. In this case, if the price doesn’t leave the range of LP1’s position, he will get 3x more fees than LP2. That’s because LP2 has only $1 in this range. And this $1 is competing with $3 of LP1.
If you look at the liquidity distribution of any Uniswap v3 pool, you’ll see it’s not uniform.
The higher the bar, the higher the competition. Liquidity providers need to find the balance between choosing competitive ranges and the range with a lower probability of a price hit. That’s why this distribution plays a big role in LP profit prediction and strategy building. The only problem is… I’m not sure this distribution is calculated properly.
Being a liquidity provider is about guessing the price, competition state, and trade volume. If an LP had a wish, it would be to know the future of the trades to adjust liquidity positions beforehand.
But what if I tell you it’s possible?
While researching, some unusual liquidity providers caught my attention. They added and removed significant liquidity positions (over $10m) many times a day. Even more surprising, they always added and removed liquidity in the same block.
Let’s look at an example:
We have three transactions, all in block 15413416, positions 3-5, executed in bottom-up order. The first transaction, with the Execute method, is a contract named “MEV Bot,” adding $22m of liquidity to the USDC-WETH pool.
The second transaction is a swap from USDC to DogeChain through WETH. This is an ordinary swap with a value of approximately $16,500.
The third transaction is “MEV Bot” again, removing $22m liquidity from the USDC-WETH pool.
What happened in the example is called “liquidity sniping”. Let me explain how this worked:
So, his gross profit after gas fees was around $30. Not very much? Yes, but he executes this strategy multiple times a minute, which all adds up. You can check it out yourself.
What does this mean for you as a liquidity provider? It means liquidity snipers could take a significant cut of your fee profits.
Let me wrap up my research findings:
Luckily, you can now better understand how Uniswap v3 liquidity pools work in real life and can adjust your research accordingly.
I’m not in a position to give financial advice, but I see only 2 options to build a prominent liquidity-providing strategy:
Both options have one thing in common—you’re basing your decisions on data rather than a gut feeling or random tools. Sometimes working with data is tough, but it pays off.
At Datamint, we’re always here to help you with your custom data projects.
May the data be with you!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.