L2BEAT and DefiLlama use different methodologies for calculating TVL. L2BEAT accounts for all assets locked in Ethereum contracts, including L2-native governance tokens (ARB, OP), while DefiLlama focuses on assets actively engaged in dApps on specific networks.

Let's assume L2BEAT reports a TVL of 2.5 billion, while DefiLlama reports a TVL of 1 billion for the same Layer 2 network (e.g., Arbitrum). This suggests that 1.5 billion worth of assets have been bridged to Arbitrum from Layer 1 (Ethereum), but are not yet being used in any dApps listed by DefiLlama. For instance, if you deposit 1 ETH to Optimism, L2BEAT would include it in their TVL calculation, but DefiLlama would not. However, if you use that 1 ETH on Optimism to provide liquidity on Uniswap, DefiLlama would then include it in their TVL calculation. Also, at L2BEAT, the value of L2-native governance tokens is included, which adds to the discrepancy.

The discrepancy in reported TVL between L2BEAT and DefiLlama is due to different interpretations of "Total Value Locked." L2BEAT considers the entire Ethereum ecosystem, while DefiLlama emphasizes assets used in dApps on individual blockchain networks.

Trust-minimized L2s are chains that can be exited by interacting directly with L1 alone, eliminating the need to rely on L2 operators for the security of the funds.

In the case of Polygon, an additional layer of trust is introduced: users must trust the majority of Polygon's validators to enable secure withdrawals and prevent fund theft. Note that application-specific logic, like in the case of dYdX forced trade requests, may also require inter-user dependencies to successfully exit the system.

We want to track the progress of the projects that are credibly committed towards becoming trust-minimized L2s. Our goal is to provide the community with the most up-to-date information about the state of these projects and to provide insights and guidance for them to become fully trust minimized.

Validiums and Optimiums are not L2s: by not publishing data on L1 they introduce additional trust assumptions on top of it. If the data to reconstruct the state is not made available by the operators of the offchain DA solution, funds are at risk.

We include Validiums and Optimiums along with L2s mainly for historical reasons. We introduced them when the L2 space was still in its infancy and we wanted to provide a comprehensive overview of the space. We will continue to track these projects to provide the community with a broader perspective on the state of the space and to provide tools to evaluate the different tradeoffs between the various solutions.

There are two primary (and somewhat independent) mechanisms that L2 chains use.

First, the L2 state can be verified by L1 through either Validity Proofs or Fraud Proofs. This mechanism is most important as it ensures that L2 proposers cannot cheat and include invalid transactions in an L2 block, e.g. mint coins out of thin air or steal your coins.

The second use of L1 is as a Data Availability layer for L2 transactions so that users can independently re-create the L2 state and ensure continued and safe system operation or trustlessly exit to L1.

An L2 chain can periodically "commit" its state to L1 by submitting the hash of its current state root. A state root is just a number, e.g: 0x77905a71f4b32221... . We need a mechanism to ensure that this number corresponds to the actual L2 state.

One way to do so is by providing a cryptographic Validity Proof (zkProof) that will be verified by the L1 smart contract. If the verification passes, users can be sure that the state root represents the results of valid transaction execution.

Alternatively, an honest L2 chain observer can challenge roots. They can do this by producing a Fraud Proof. This proof empowers the L1 contract to autonomously confirm the inaccuracy of the state root and subsequently reject it.

To trustlessly withdraw coins from L2, users need to prove ownership of the coins to L1 smart contract that holds all the funds. For that they need to have access to all L2's transactions or its current state. To not introduce any additional trust assumptions, L2 transactions can simply be recorded on L1 (as cheap calldata).

For more details on data availability and its importance in security of scaling protocols, see Ethereum.org's page on the topic.

We currently acknowledge the following possible designs of trust-minimized L2s:

• zkRollups - they publish data on L1 (Ethereum) to inherit data availability and consensus guarantees, and use validity proofs to guarantee state roots correctness.
• Optimistic Rollups - they publish data on L1 to inherit data availability and consensus guarantees, and use fraud proofs to guarantee state roots correctness.
• State channels - they don’t publish data onchain, but require users to keep their data in order to exit. They’re not general and require users participation.
• Plasma - they don’t publish data onchain and use fraud proofs for disputes. Similarly to state channels, users are required to keep their data to correctly exit. They don’t require users participation, but they do not support general computation.

By introducing more trust assumptions we can also specify the following categories that fall outside of the L2 boundary:

• Validiums - Those systems rely on validity proofs and data published externally.
• Optimiums - historically named Optimistic Chain. Those systems rely on fraud proofs and data published externally.

For more details see the Incomplete guide to Rollups by Vitalik Buterin.

It varies from project to project but in general, the TVL is defined as the sum of canonically bridged, externally bridged, and native assets of a given L2. Depending on the token type we might apply a different formula to count the value of this particular token:

• Canonically bridged tokens: tokens_locked_on_L1 * price
• Externally bridged tokens: total_supply_on_L2 * price
• Omnichain native tokens: total_supply_on_L2 * price
• Regular native tokens: circulating_supply * price

Please note that in some cases formula might actually be different (for example we may use circulating supply instead of total supply for some tokens)

• Canonically Bridged Value (CBV) is the value of assets that use L1 Ethereum as their main ledger and are bridged to L2 via a canonical bridge locking tokens in L1 escrow and minting on L2 an IOU representation of that token.
• Externally Bridged Value (EBV) is the value of assets that use some external blockchain as their main ledger and are bridged to L2 via a non-canonical bridge. Tokens are locked on their native ledger and the bridge is minting on L2 an IOU representation of that token.
• Natively Minted Value (NMV) is the value of assets that use an L2 as their ledger and are minted directly on the L2. Note that for some tokens (omnichain tokens) their ledger is distributed across many blockchains and they can be moved to L2 via a burn-mint bridge.

For more information read the L2 Assets blog post.

We are currently focused mainly on rollups, but would love to expand our research to state channels in the future. For the time being we lack resources to properly evaluate those systems.

Nahmii was actually listed on L2BEAT for a time, but was removed for the reason stated above. If you want to check TVL for Nahmii you can do that on etherscan.

Everything is open source – just create a PR. If you want to add a new project you should read our contributing guidelines.

🔍 Here is also a visual step-by-step guide for creating a Pull Request - link