messari
Uniswap V3 QA (Arbitrum) Schema Version 1.3.0 Subgraph Version 1.1.1 Methodology Version 1.0.0
| Description | Value |
|---|---|
| Subgraph Reviewed | https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/messari/uniswap-v3-arbitrum&tab=protocol |
| Date Reviewed | July 18 2022 |
| Schema Version | 1.3.0 |
| Subgraph Version | 1.1.1 |
| Methodology Version | 1.0.0 |
| Evidence Spreadsheet | https://docs.google.com/spreadsheets/d/1nhu2rqFYM8TuV9DlrksQTAOnP-3L-WsY/edit?usp=sharing&ouid=113156017090580515789&rtpof=true&sd=true |
Metrics To Review
Protocol Metrics
| Section | Metric | Issue |
|---|---|---|
| financialsDailySnapshots | totalValueLockedUSD | The subgraph TVL is about 20% less than the TVL from DefiLlama. Furthermore, the trends look decent, except for between 02/06/2022 - 02/08/2022 there is a spike in the subgraph that is different than both DefiLlama and Uniswap UI. See protocol tab on evidence sheet. |
| financialsDailySnapshots | dailySupplySideRevenueUSD | QA'er made a note that the recent average daily revenue/volume on subgraph (Arbitrum) is higher than Dune's data (Uniswap V3 on Ethereum), which may warrant attention. I think this metric is most likely fine since the daily volume seems to be ok, but just want to make sure that we are accounting for Uniswap V3 having different fees for different pools. If this is the case, then this is probably ok. |
Pool Overview
| Pool | Metric | Issue |
|---|---|---|
| All Pools | Fee Labels | Missing labels for pools with different fees since there can be pools of the same assets, but with different fees. For example, WBTC/ETH 0.3% and WBTC/ETH 0.05% |
| Some Pools | Naming for ETH | Pools with ETH are missing ETH in the pool name and in the input tokens. Right now it is just blank. For example, Uniswap V3 ETH / GMX is being shown as "Uniswap V3 /GMX" and the input tokens are being shown as ", GMX" |
| Some Pools | Naming for USDC and USDT | Pools with USDC and USDT seem to be having a weird name convention where in the pool name they are being called arbFiatToken and being output as "FIAT" in the input token section |
| All Pools | Base Yield | Yields are in the high hundreds and thousands for most pools, which is not correct. Would be great if true though. |
| Uniswap IUSD/USDT | All Metrics | This pool seems to be missing from pool overview when it is the 2nd highest pool in TVL on the Uniswap Arb UI. Link - https://info.uniswap.org/#/arbitrum/pools |
| Uniswap V3 ETH/GMX | TVL | Subgraph pool is outputting ~9m when Uniswap UI is outputting ~24m. Link - https://info.uniswap.org/#/arbitrum/pools |
| Uniswap V3 UMAMI/ETH | TVL | Subgraph pool is outputting $727,637.53 and Uniswap UI is outputting 1.3m. Link - https://info.uniswap.org/#/arbitrum/pools |
Note - Seems like there is a mix of correct and incorrect TVL values. I just listed a couple incorrect ones above.
Pool Metrics Data is not loading, so individual pools could not be checked.
What do you mean by yields? Like the protocol and supply side revenues?
Ya. Base yield I believe refers to the yield generated from fees for LPs opposed to reward APR which is from emissions (ex. SUSHI). Should be supply side revenue in this case since Uni does not have protocol revenue IIRC
These are different things though. Like in Sushiswap, the reward emissions which are used to populate rewardTokenEmissionsAmount and rewardTokenEmissionsUSD are calculated based on a daily rate. This is not present in Uniswap V3. The trading fee and protocol fee are present in both of these protocols, though, and they are not calculated as a rate - rather they are calculated as a cumulative value for the entity. Are we on the same page with this or am I misunderstanding something?
These are different things though. Like in Sushiswap, the reward emissions which are used to populate rewardTokenEmissionsAmount and rewardTokenEmissionsUSD are calculated based on a daily rate. This is not present in Uniswap V3. The trading fee and protocol fee are present in both of these protocols, though, and they are not calculated as a rate - rather they are calculated as a cumulative value for the entity. Are we on the same page with this or am I misunderstanding something?
Sorry, I think I was being unclear in my first statement and I believe that we are on the same page. I am currently under the impression that "Base Yield" refers to the fees generated by swaps and is unrelated to reward tokens; thus, the "base yield" metric shown on the pool overview page should be based on the revenue value. I was just trying to make clear in my previous statement that I think that yield should be referring to fee revenue and not reward tokens, but I could be wrong about this.
All good! Just wanted to be sure. So what are you referencing to check that these values are off? The swap fees should be between 0.05% and 1%. If the total volume of a liquidity pool is $10 Million, then it would have generated between $5,000 and $100,000 in revenue. Many of these pools have volumes around and above $100 million ($50,000 to $1,000,000 in revenue).
All good! Just wanted to be sure. So what are you referencing to check that these values are off? The swap fees should be between 0.05% and 1%. If the total volume of a liquidity pool is $10 Million, then it would have generated between $5,000 and $100,000 in revenue. Many of these pools have volumes around and above $100 million ($50,000 to $1,000,000 in revenue).
I am just guesstimating based on the the fees over the last 24 hours output on the Uniswap UI. For example, GMX/ETH 1% pool generated $22.31K in fees on 07/18 with a pool TVL of roughly $24.4m . I think Solarbeam calculates yield as lastDayVolume * fee * 365 * 100) / pool TVL (assumes daily fees are standard for the year) and if we use that calculation as a baseline it is around 33.3% for the pool, which is still far off from the 6k%. The base yield should be dynamic though because trading fees ebb and flow with volume and I am also not sure over what length of time we are calculating the base yield, but I feel like 6k% is generally very high for yield based strictly on swap fees. Link to GMX/ETH Uniswap UI - https://info.uniswap.org/#/arbitrum/pools/0x80a9ae39310abf666a87c743d6ebbd0e8c42158e
Why time lastDayVolume * fee * 365 * 100) / pool TVL in this equation? It make more sense to me to leave that out. Also, the fees should always just be Fee * VolumeUSD. If this is not the case, then it is wrong.
Like here in ETH/GMX, the cumulative volume is 577 Million. Because the fee is 1%, then 5.7 Million in swap fees have been dished out over the life of the pool. This seems correct to me.
Yes, I agree on how the fee is being calculated. I was just using that equation as an example of how base yield could be calculated since it's giving LPs a yield number based on the most up to date fee volume. I am not exactly sure what the standard is for our subgraphs, but I think cumulative supply side revenue / TVL is generally not correct since its not an accurate display of the yield LPs would get if they deposited liquidity in present time.
Would it not be a decent estimation though if you are using the daily volume and fees with whatever the TVL is at that time?
I agree that you would not want to use cumulative volume to project he revenue, but using a smaller snapshot like the daily volume and revenues does seem apt. Is this not the way it is specified to calculate?
If you are doing cumulative volume * Fee * 365, then I could see why the values are way off, because this is projecting like all the cumulative revenues from the pool have been earned in the past 24 hours.
Yes, I think we are in agreement about this ... I am just being confusing. I was just using solarbeam equation as like even if we use this equation that accounts for standard fees and TVL for a whole year it is still less than 6k%. I agree on (daily volume * fee)/(daily TVL) is the most accurate, but I do not think this counts as APR since its over a daily time period, so just depends on if we want to refer to base yield as like daily yield or APR.
Okay - we are merged in and deployed. The subgraph is indexing under the pending version as of yesterday.
Okay - we are merged in and deployed. The subgraph is indexing under the pending version as of yesterday.
Sweet. Thanks, will take a look at it after it has indexed further.
| Description | Value |
|---|---|
| Subgraph Reviewed | https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/messari/uniswap-v3-arbitrum&tab=protocol |
| Date Reviewed | 7/25/2022 |
| Schema Version | 1.3.0 |
| Subgraph Version | 1.1.0 |
| Methodology Version | 1.0.0 |
| Evidence Spreadsheet | https://docs.google.com/spreadsheets/d/139hB-46pGIn34TESq3waBjp_c5TEU2tJ/edit?usp=sharing&ouid=113156017090580515789&rtpof=true&sd=true |
Metrics To Review
Protocol Metrics
| Section | Metric | Issue | |
|---|---|---|---|
| financialsDailySnapshots | totalValueLockedUSD | The subgragph TVL is within comfortable ranges compared to DefiLlama, but is >20% difference than the Uniswap Arb UI. I think this may be becasue of how the TVL is being calculated for certain pools that have funky token pairs. Seems like the major token pairs have the correct TVL and some exotic pairs are very different, which could be the difference in overall TVL. Thus, I would probably be fine with this metric if its a pricing library issue, but there is a weird spike between 02/06/2022 - 02/08/2022 that does not follow the general trend of DefiLlama and Uniswap UI. |
Pool Overview Comments - The TVLs for "common" pairs (ETH/USDC) seem correct, but a lot of the lower TVL with more exotic pairs are not returning the same TVL as the Uniswap UI. Uniswap UI be wrong, but probably smart to double check those pools. I linked a few of them below along with the arbscan links. I am leaning towards Uniswap UI being wrong, since they have a iUSD/USDC pool that seems to be a fake liquidity-bomber-type pool (arbscan link goes to an empty contract address, but I linked it anyways).
| Pool | Metric | Issue |
|---|---|---|
| Uniswap iUSD/USDC | Existing | https://arbiscan.io//address/0x69d483e56638703ca1023a071ff471639e194edf |
| Uniswap V3 ETH/GMX 1% | TVL | https://arbiscan.io//address/0x80a9ae39310abf666a87c743d6ebbd0e8c42158e |
| Uniswap V3 UMAMI/ETH 1% | TVL | https://arbiscan.io//address/0x2b734ec7555cb49c755a9495a8d17cd2383926e0 |
| Uniswap V3 GMX/USDC 1% | TVL | https://arbiscan.io//address/0x2039f8c9cd32ba9cd2ea7e575d5b1abea93f7527 |
| Uniswap V3 USDR/USDC 0.05% | TVL | https://arbiscan.io//address/0x78727cc9e4bcbbceb15e3c4b7155f997fa365ce1 |
| Uniswap V3 ETH/GMX 0.3% | TVL | https://arbiscan.io//address/0x1aeedd3727a6431b8f070c0afaa81cc74f273882 |
| Uniswap V3 ETH/DBL 0.3% | TVL | https://arbiscan.io//address/0x08687dd94b1e084808b549fb5594d6e3d3b7b948 |
| Uniswap V3 ETH/LINK 0.3% | TVL | https://arbiscan.io//address/0x468b88941e7cc0b88c1869d68ab6b570bcef62ff |
| Uniswap V3 ETH/TAC 0.3% | TVL | https://arbiscan.io//address/0x0e075f9f5496ae70e35e6ae25d13c990f1f092f0 |
| Uniswap V3 CRV/ETH 1% | TVL | https://arbiscan.io//address/0xba80cede54bf09f8160f7d6ad4a9d6ae3a9852d9 |
| Uniswap V3 APEX/ETH 0.3% | TVL | https://arbiscan.io//address/0xefd07239232e19d78e603122119637506aeb21a1 |
| Uniswap V3 KROM/ETH 0.3% | TVL | https://arbiscan.io//address/0x54651ca452ad2d7e35babcff40760b7af0404213 |
| Uniswap V3 LPT/WETH 0.3% | TVL | https://arbiscan.io//address/0x4fd47e5102dfbf95541f64ed6fe13d4ed26d2546 |
@bye43 and I discussed this and determined that we can close this issue. We think that the pricing is actually okay, since the spike does not seem like an outlier.
The pools that have TVL issues seem to be the result of having a higher cutoff for token pricing. These pools have only one of the tokens being priced.
Reopening this issue since there was changes to user metrics and pricing across all chains
| Description | Value |
|---|---|
| Subgraph Reviewed | https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/messari/uniswap-v3-arbitrum&tab=protocol |
| Date Reviewed | 8/22/2022 |
| Schema Version | 1.3.0 |
| Subgraph Version | 1.1.1 |
| Methodology Version | 1.0.0 |
| Evidence Spreadsheet | https://docs.google.com/spreadsheets/d/1ItHkxqevOJk-K88_GLe_tZn7HcDU67PL/edit?usp=sharing&ouid=113156017090580515789&rtpof=true&sd=true |
Metrics To Review
Protocol Metrics
| Section | Metric | Issue |
|---|---|---|
| usageMetricsDailySnapshots | cumulativeUniqueUsers | This is too low. This is being addressed, but leaving here for tracking purposes |
Pool Metrics
| Pool | Pool ID | Comments |
|---|---|---|
| IUSD/USDT 0.05% | 0x69D483E56638703Ca1023A071Ff471639E194edf | Low volume, so I think this is fine that its blacklisted |
| ETH/DBL 0.3% | 0x08687DD94b1e084808B549Fb5594d6e3d3B7B948 | Low volume, so I think this is fine that its blacklisted |
| ETH/UNI 0.3% | 0xC24f7d8E51A64dc1238880BD00bb961D54cbeb29 | Legit token with real volume, so might need another look at pricing / blacklisting |
| ETH/LINK 0.3% | 0x468b88941e7Cc0B88c1869d68ab6b570bCEF62Ff | Legit token with real volume, so might need another look at pricing / blacklisting |
| CAP/ETH 0.3% | 0x3Be3EBc2C4c0e65d444D6254aE9b1486F0d801EE | Low volume, so I think this is fine that its blacklisted |
| MAGIC/ETH 1% | 0x7e7FB3CCEcA5F2ac952eDF221fd2a9f62E411980 | Legit token with real volume, so might need another look at pricing / blacklisting |
| APEX/ETH 0.3% | 0xEFd07239232e19D78e603122119637506aEb21a1 | Low volume, so I think this is fine that its blacklisted |
| ETH/TCR 1% | 0xE8BfB2918853576f0965E29Bb86001ea93019003 | This has some volume, but I think its because tracerdao got acquired, so probably why for the uptick. This is fine blacklisted |
| ETH/rETH 0.05% | 0x09ba302A3f5ad2bF8853266e271b005A5b3716fe | TVL is low here, but I think there is organic volume and rETH is a legit token, so might need another look at pricing / blacklisting |
| DPX/ETH 1% | 0xb52781C275431bD48d290a4318e338FE0dF89eb9 | This is a real token, but the pool looks whack, so its fine that its not included / blacklisted |
@this-username-is-taken @steegecs Closing this issue, as its being frozen for Mainnet. Newer issues being tracked here: https://github.com/messari/subgraphs/issues/984