Methodology for calculating chain TVL

[0xngmi]

The methodology we use to calculate the TVL of each chain along with the total TVL just involves summing the TVL of each project on that chain.

This means that we are introducing some double-counting into the metric due to the composability of DeFi.

Let's use Maker as an example, you can lock 10 ETH there and mint 100 DAI, which you can then use on a Curve LP. In this case we will count the 10ETH towards Maker TVL and the 100 DAI towards Curve TVL, and when we sum them together to get total TVL the result will be 10 ETH + 100 DAI. However, there has only been 10 ETH deposited on DeFi, so you can argue that we are double counting some assets.

This gets more complex due to composability within defi protocols. Someone could take the DAI that we mentioned earlier and deposit it on yearn instead, which will then deposit the DAI on a mixture of protocols such as compound, aave or curve. After that, the user could take the yDAI they receive and use it to borrow money on MIM and then use that MIM to LP on curve. The result of this is that the money generated by the initial 10ETH deposit easily ends up in more than 10 different protocols, which all get added together for the total TVL.

Other TVL aggregators attempt to remove this double counting by just removing the TVL of some protocols from total TVL, but this approach leads to incorrect data. One of the most basic protocols, aave, has deposits in a lot of basic assets such as ETH and USDC, but it also has DAI and uniswap LP tokens, so if you include it into the TVL sum you will introduce some double counting, yet if you exclude it you will be excluding a lot of TVL that should be counted. Anything you do will lead to incorrect data.

The proper solution would involve correctly tracking interactions between protocols and excluding TVL very selectively. However, this becomes a sisyphean task with protocols launching new pools every day and new assets emerging every day, so keeping this up to date would be impossible for us.

For these reasons, we are left with the decision of doing a half-assed job and providing incorrect data, or owning it, setting this as our methodology and providing the correct data. For now we prefer the latter.

Furthermore, it's not entirely clear if double-counting through composability is something that you want to avoid. Chain TVL is usually used as a metric for defi adoption on a chain, and composability between protocols is something that is interesting to track in that scenario.

This is our current stance on the subject, however we are open to changing it if our users want it. This doesn't have to be a binary decision between removing double counting or not, instead there are multiple other solutions, such as creating a toggle that lets users choose between double-counted but correct data, or incorrect non-double-counted one. If our users want it we'll build it, just let us know.

[0xngmi]

More arguments and discussion on https://twitter.com/0xngmi/status/1436706971864993795