Why separate staking & pool2 from core tvl

[0xngmi]

The reason why we separate staking and pool2 tvl apart from normal tvl is to keep comparisons fair between protocols. For sushi or curve we don't count xSUSHI or veCRV into their TVL (same applies with a lot of other protocols with staking), so it would be unfair to count CAKE staked on PancakeSwap or ILV staked on Illuvium.

Another solution would be to count staking for all of them, however there are 2 main issues with this:

• Most users I've spoken with don't agree with counting this as TVL, since they use TVL as a proxy for adoption and trust and staking of the protocol's own token doesn't reflect that (except in some cases where the protocol is staking, such as synthetix). However, we recognize that some users also want to count this and the protocols themselves tend to want this as well, so our solution here is to separate these different tvl sources and let the user choose how they want to define tvl by themselves (they can pick what to include into tvl on our webpage)
• Historically we haven't counted staking for all the major protocols, so to keep our methodology backward compatible it's best to keep only counting the same stuff we were counting before and keep new tvl sources separate

Regarding the data that we provide to 3rd party sites such as coingecko or CoinMarketCap, the reason we've built the api this way is to keep it backwards compatible. We only started counting staking and pool2 recently, so earlier when coding adapters we just didn't include these at all. This means that now we have some adapters that include staking but not for others.

If we reported tvl to coingecko/cmc as the total sum of all sources of tvl, we'd be drawing unfair comparisons between protocols, since the new additions would have extra sources of tvl that the old protocols don't have (we are slowly fixing the old ones but it takes time). Furthermore, there's the issue of what to consider tvl, as there's a wide range of opinions on what should be counted and what shouldn't.

Not just that, but if we suddenly added this to the api, we'd be changing our methodology. So to keep our api backwards compatible we've maintained the tvl number under the old methodology the same and then added new additions that can be summed together by the parties that integrate us.

So, wrapping it up, our solution to this is to export the multiple tvl sources separately and let 3rd parties that integrate us such as coingecko choose how they want to define tvl.