Reworking TVL on L2BEAT

TVL is one of the most controversial and, at the same time, one of the most used metrics to assess the “popularity” of the chain. When L2BEAT was launched, a somewhat simplistic but easily verifiable approach was taken to report the TVL of a given chain - namely, all tokens locked in a bridge (i.e. tokens moved to a given Layer2) are counted and priced using some publicly available APIs. This approach, while it seemed ok at the beginning, led to a set of problems:

  • Manipulation - It is too easy to create a token with a massive Max Total Supply, provide some liquidity with the potentially fake volume on any of the decentralized DEX-es, and inflate massively total market cap. When most of these tokens are then locked in a bridge and moved to L2, even though they are still totally illiquid, the total TVL in a bridge gets artificially inflated
  • Omission of L2 native assets - If a token is minted on L2, even though it may be very liquid and have real economic value, since it is not bridged, it will not appear on the TVL for this rollup
  • Counting associated tokens - Some L2s have their native tokens, while some do not. If users are to get a fair comparison of TVL for different L2s, it makes sense for them to exclude native tokens for some comparisons, especially if they comprise a significant percentage of the TVL locked in a bridge
  • No precise definition - TVL, as reported on L2BEAT is different than TVL reported on other platforms, like DeFi Lama. This is confusing to end-users and arises from the fact that TVL is not a well-defined and agreed-upon metric.

It is clear that the TVL metric on L2BEAT needs an overhaul and we seek the community input for what would be the fairest and most objective metric(s) with the following being our current proposal

TVL vs AUM

The case of Optimism

Recently Optimism has launched their new token - OP as an airdrop on their L2. Up to this point, we had a policy of counting the tokens locked in a bridge if the token is in the top 300 on Coingecko or if it is an associated token for a platform, e.g. LRC for Loopring. With OP’s launched we had a decision to make: list the token because it is associated which follows the “native token” rule but breaks the “locked in a bridge” rule or not list the token and follow “locked in a bridge” but break “native token”.

To solve this conundrum we decided to track the OP token but only up to the circulating supply as determined by Coingecko. In our opinion using the circulating supply instead of the total supply is fairer because the market only trades the coins in circulation and so only their value can be determined.

This however presented a problem for other L2 native assets that we haven’t previously considered. Should they now be included in TVL too?

Splitting the metrics

Instead of one “TVL” metric, we propose to have two distinct, precisely defined metrics, namely TVL and AUM.

TVL - Total Value Locked - For every L1 bridge escrow that stores user funds and for every token in that contract sum the minimum of the balance of the token in that contract and the circulating supply of that token multiplied by the price of that token. This is most similar to the way current TVL is calculated and can be thought of as a maximum bounty for a hacker that manages to steal tokens from L1 bridge escrow. This metric will not take into account tokens that are minted on L2. See the pseudocode below:

let sum = 0
for e in bridgeEscrows
    for t in tokens
        value = min(balance(e, t), circulatingSupply(t))
        sum += value * price(t)

AUM - Assets Under Management - For every token on L2 sum the minimum of total supply on L2 of that token and the circulating supply of that token multiplied by the price of that token. Conceptually this is the total value that would be lost if the L2 disappeared without having a way to recover the managed funds. This metric could potentially also encompass NFTs in the future. See the pseudocode below:

let sum = 0
for t in tokens
    value = min(L2totalSupply(t), circulatingSupply(t))
    sum += value * price(t)

Values:

  1. L1 total supply - as reported by the totalSupply function of the ERC20 contract of a particular token on Ethereum.
  2. L2 total supply - as reported by the totalSupply functions of all the ERC20 (or equivalent) contracts of a particular token on a particular L2.
  3. circulating supply - as reported the token page of a particular token on Coingecko.
  4. bridge balance - as reported by the balanceOf function of the ERC20 contract of a particular token on Ethereum.
  5. price - as reported the token page of a particular token on Coingecko.

Filtering small-cap tokens

To prevent easy manipulation of both metrics we will have a whitelist of tokens that we track. Following our current rules, only the top 300 coins from Coingecko will be considered with exceptions for tokens associated with a given L2 (e.g. LRC for Loopring).

While this is not a perfect solution we can’t vet every single token that is moved to a bridge. To ensure that some legitimate tokens make it to the TVL even though their total market cap falls outside the top 300 list, we will be maintaining a whitelist and easy-to-use request form for anyone to get their token counted.

Total Supply vs Circulating Supply

Given that Coingecko only takes into account the circulating supply of tokens, and it is generally very hard to individually keep track of what is circulating supply, we will rely on Coingecko’s reported circulating supply which will be taken into account, especially for L2-minted tokens.

When counting the value of tokens if the balance or total supply reported by the contracts would exceed the circulating supply reported by Coingecko we will use the circulating supply instead.

Examples:

  • A new coin is minted on L1, all of it is immediately bridged to L2 and then only some of it is being airdropped to the community. Most likely Coingecko will report the amount airdropped to the community as the circulating supply and so the TVL would equal the circulating supply multiplied by price as opposed to counting the full balance which would result in a bigger number,
  • A coin is minted directly on L2, but only a small portion is actively traded. Even though the reported total supply is quite large, the circulating supply reported by Coingecko is low. The AUM for that coin would therefore equal the circulating supply multiplied by price.

Tokens associated with projects

Currently, the site only displays a warning if a large percentage of the TVL is composed of tokens associated with a project.

We plan to add a toggle so that users will be able to choose between a view that shows TVL and AUM with or without native tokens. Additionally, if the toggle is switched on, we will again warn users that a significant percentage of TVL or AUM is comprised of the native token.

7 Likes

Kelvin from Optimism here, wanted to drop my 2c on the topic.

First, I think it’s important to acknowledge that defaults are very powerful. Giving toggles to display different metrics may be useful for a subset of users, but I’d be willing to bet that the vast majority of users will simply view the site as initially presented.

That said, I want to challenge the idea of a hard ranking on L2Beat based on TVL. I understand the desire to measure the relatively popularity of different projects, and TVL is an easy (if flawed) way of attempting to do this. L2Beat has become a core part of the L2 ecosystem – people look at L2Beat when deciding which system to use. By presenting an ordered list of projects by TVL on the main page of L2Beat, the site is bestowing a significant advantage to incumbents and simultaneously incentivizing projects to seek TVL over other more long-term beneficial metrics.

As L2Beat becomes more and more influential, projects near the bottom of the TVL list are at more and more of a disadvantage. Take zkSync, for instance, which has ~1.5% marketshare by TVL but has a 0% chance of appearing near the top of my screen when opening L2Beat (on mobile, at least, where I only see up to #5 on the list before I have to scroll down). Strict ranking by TVL promotes a winner-take-all reality similar to first-past-the-post voting. This is reinforced by the numbering system used by L2Beat: presenting a project as “#1” or “#2” suggests a subjective “betterness” over a project listed as “#15”. I understand that this is not the intent of L2Beat, but it is the effect.

I would therefore propose an alternative change: use a weighted shuffle based on TVL instead of a strict ordering and remove the numbered list.

This means that a project with 1.5% of all TVL would be at the top of the list 1.5% of the time (on average). Doing this would not bestow a value/“betterness” to a project based on the flawed metric of TVL, while also giving smaller projects a chance to appear near the top of the page. I think this would have a significant positive impact (for all the reasons listed above), would reduce the incentive to chase TVL, and would increase decentralization by decreasing incumbent power.

Generally speaking, my stance is that TVL is not a strong enough metric to justify a strict ranking on something as important to the ecosystem as L2Beat.

4 Likes

Hi all!. Reviewing all the ideas, I always lean towards a simple solution for users to understand and not continually ask themselves “how is this calculated” or “I don’t understand why this number is different from X (eg defillama)”.

About filtering, considering TVL with a minimum ranking for tokens (top 300 on coingecko) will drive out all sorts of humble native L2 projects (including tokens with mcap >50M right now).

The question is: has sense measure the true total TVL of a network? Let’s try with Ethereum itself, maybe impossible.

What about split the number in two categories: L1 funds (bridge) and TVL on DeFi? for me looks a fair approach, in this case effectively we could add the whitelist thing and anti-manipulation via massive max total supply (and the people can activate the checkmark) in case anyone wants to watch the plain L1 funds vs a curated number. And TVL on DeFi, just use metric provided by defillama if we want it to be so. Later let the people reorder the rank selecting any of these metrics. Obviously a app-specific L2 could be have a “-” mark in TVL on DeFi.

1 Like

That is a very interesting proposal, but it does have some problems associated with it that make it a much harder sell:

  1. As a designer of the system we can think of a distribution of different places in the ranking depending on TVL. But as a user we only see one snapshot of a distribution, which makes it confusing, because there seems to be no apparent logic to one particular snapshot - it was decided by weighted randomness
  2. “This means that a project with 1.5% of all TVL would be at the top of the list 1.5% of the time” - this unfortunately means that even though the solution aims for being fairer, projects currently on the bottom of the list e.g. StarkNet (0.01%) or Aztec (0.13%) have a very low realistic chance of moving anywhere from that spot

If the issue is that projects lower in the ranking aren’t featured enough maybe elevating a single random project (not based on TVL) to the top every day and marking is as “Featured today” would solve this problem.

If the issue is that TVL is too flawed to base the list on, I think that adding more metrics would be a solution and this is something that we’re working on.

I am curious to see what other people think.

1 Like

About filtering, considering TVL with a minimum ranking for tokens (top 300 on coingecko) will drive out all sorts of humble native L2 projects (including tokens with mcap >50M right now).

True, but this is why we also plan to make exceptions on a case by case basis. Having an arbitrary line is necessary, because we simply can’t include everything as not every token even has a value.

What about split the number in two categories: L1 funds (bridge) and TVL on DeFi?

I think that is an interesting suggestion, but most L2s don’t have really have DeFi on them, so this metric is quite limited. Also, Defi Llama operates on data self reported by the projects, so there is a big issue of trust in the metric. We gather the data ourselves.

Hi, I’m Michael, I work on data things at OP Labs, but my personal takes:

I’m a fan of the AUM-style metric over bridge TVL for L2s, primarily for the “Omission of L2 native assets” mentioned above.

  • We’ve taken a stab at this with “On-Chain Value”, but this also re-introduces some of the token pricing problems above, where a token can trade a few times at some high market cap, then become illiquid (i.e. deposit-receipt tokens - also a double counting risk). I’ve so far tried to manually exclude these tokens when we find them, but maybe some rule like “needs to have been traded with X volume within the last Y days” could mitigate this.
  • There’s also nuance with cross-chain bridge AMM tokens (i.e. Hop’s hETH, Synapse’s nETH). In “On-Chain Value”, we’ve used recent bridge events to calculate the hETH<>ETH ratio to approximate the hETH price in liquidity pools. It’s complex since these get swapped within the bridge contracts vs a DEX, so it’s required custom building for every cross-chain bridge, but maybe there’s a better method.

For “Counting associated tokens”, I think this would make sense as a toggle. To Kelvin’s points above, the “default” is tricky. An “apples-to-apples” comparison today may be filtering out associated tokens, since not every L2 has an associated token. But, as these tokens become more prevalent in DeFi, I see it becoming a gray area (i.e. are we actually measuring AUM, or just the market cap of each L2’s token).

Other metric ideas that could be useful for a more complete view: Fees Paid on L2 in ETH, Total L1 Gas Used, an “efficiency” metric like L1 Gas Used per L2 Transaction (or per L2 Gas Unit if applicable), # L2 Transactions, # Transacting Addresses on L2. Some examples of fees and gas used metrics here.

Excited to see the updates!

2 Likes

Hi all – first off am a huge fan of L2Beat as a resource and kudos to the community for being thoughtful with data presentation and highlighting risks.

I would second @MSilb7’s suggestion above and potentially add ‘daily active addresses’ and L2 fees. Maybe something like DAU/MAU ratio too as a proxy for user (address) engagement which feels like an important measure? TVL is a somewhat fraught metric and think something more objective, that still accomplishes the goal of measuring “activity,” might be helpful for the community. Even if we collectively agree on a more robust definition, TVL does not capture non-DeFi activity.

1 Like