Detailed Instructions

First, identify the primary cross-chain bridge contracts (e.g., Wormhole, LayerZero, Axelar) that lock assets on a source chain to mint wrapped versions on a destination chain. The native assets (like ETH or USDC) are double-counted in TVL: once in the source chain's bridge vault and again as the wrapped asset (e.g., wETH) on the destination chain's DeFi protocols. For example, 100 ETH locked in the Wormhole bridge on Ethereum and minted as 100 Wrapped Ether (WETH) on Solana would be counted as 200 ETH in aggregate TVL, despite representing the same underlying value.

• Sub-step 1: Query the bridge's locking contract on the source chain (Ethereum) to find the total value deposited. Use a block explorer or an API call to the contract's totalLocked function.
• Sub-step 2: Track the corresponding minting contract on the destination chain (Solana) to sum the circulating supply of the wrapped asset.
• Sub-step 3: Compare the two values; they should be nearly identical, confirming the double-count.

Tip: Use DeFiLlama's or Dune Analytics' bridge dashboards to see real-time examples, such as the Wormhole bridge holding over $1.2B in assets, which are simultaneously reflected in Solana's and other chains' TVL.

Detailed Instructions

Omnichain liquidity pools like Stargate or THORChain allow users to provide a single asset (e.g., USDC) that is deployed across multiple chains via underlying bridge infrastructure. This single deposit is often counted as TVL on each chain it supports, leading to significant TVL inflation. For instance, a user depositing 10,000 USDC into Stargate's Ethereum pool for cross-chain swaps might see that liquidity counted on Ethereum, Arbitrum, and Polygon, potentially tripling the reported TVL from that single capital source.

• Sub-step 1: Identify the omnichain pool's master contract (e.g., Stargate's Router on Ethereum at 0x8731d54E9D02c286767d56ac03e8037C07e01e98).
• Sub-step 2: Use the contract's totalLiquidity or poolInfo function to get the total value locked per chain.
• Sub-step 3: Sum the liquidity reported across all supported chains and compare it to the actual aggregate user deposits tracked by the protocol's internal accounting.

Tip: The distortion is evident in protocols like THORChain, where a single RUNE deposit supporting multi-chain liquidity can be counted multiple times across its connected chains (Bitcoin, Ethereum, etc.), inflating its reported TVL by factors of 2-3x.

Detailed Instructions

Rehypothecation occurs when a collateral asset (e.g., stETH) locked in Protocol A on Chain X is used as collateral to borrow a stablecoin, which is then deposited into Protocol B on Chain Y via a bridge. This creates a chain of leveraged TVL where the same underlying asset supports multiple locked positions across ecosystems. For example, 100 stETH locked in Aave on Ethereum could be used to borrow 65,000 DAI, which is bridged to Avalanche and deposited into Benqi Lending, effectively counting the stETH and the DAI as separate TVL.

• Sub-step 1: Trace a high-liquidity collateral asset (like wBTC or stETH) using on-chain analysis tools (e.g., Nansen, Arkham) to identify its deployment across lending markets.
• Sub-step 2: Monitor bridge outflow transactions from the borrowing address to detect cross-chain movement of borrowed assets.
• Sub-step 3: Calculate the TVL multiplier by dividing the total value of all downstream positions by the original collateral value.

Tip: Commands like cast call on Foundry can be used to query collateral balances in lending contracts, e.g., cast call 0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9 "getUserAccountData(address)" 0xUserAddress on Aave V2.

Detailed Instructions

Aggregators like DeFiLlama sum TVL across chains, but they must decide how to account for wrapped assets. The accounting methodology (e.g., counting only canonical/native assets vs. all wrapped versions) drastically changes the total. For example, if 500,000 BTC is locked on Ethereum as WBTC, it could be counted as Ethereum TVL, but the same BTC is also native Bitcoin TVL if held in a custody reserve. A proper audit requires isolating the canonical bridge mints from synthetic or wrapped assets created by non-custodial bridges.

• Sub-step 1: For a major wrapped asset like WBTC, verify the custodian's (BitGo) on-chain proof-of-reserve against the Ethereum mint contract (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599).
• Sub-step 2: Check if the aggregator's methodology (visible in their GitHub repo) deducts bridged assets from the source chain's TVL.
• Sub-step 3: Calculate the distortion by comparing the "native TVL" (excluding all wrapped assets) with the "gross TVL" reported.

Tip: Use DeFiLlama's API endpoint https://api.llama.fi/protocols to examine the chainTvls object, which sometimes breaks out bridgedTo or liquidStaking categories to mitigate double-counting.

Detailed Instructions

Consolidate data from previous steps to compute a net adjusted TVL that removes double-counted and rehypothecated value. This involves creating a deduplication model that subtracts bridge-locked assets from destination chains and collapses omnichain liquidity to its source capital. The formula often looks like: Adjusted TVL = Gross TVL - (Sum of Bridge-Locked Value) - (Rehypothecation Multiplier * Original Collateral). For a concrete example, if the gross cross-chain DeFi TVL is $200B, and you identify $40B in bridge double-counts and $10B in rehypothecated value, the adjusted TVL would be approximately $150B.

• Sub-step 1: Compile a list of all major bridge contracts and their locked value using on-chain data or aggregated reports.
• Sub-step 2: Apply a conservative multiplier (e.g., 0.5x) to the value in omnichain pools to account for liquidity counted on multiple chains.
• Sub-step 3: Publish or compare your adjusted figure with major aggregators' "clean TVL" metrics, if available.

Tip: Scripts using the Dune Analytics API or The Graph can automate this calculation. For instance, a query summing total_value_locked from all protocols while excluding known bridge contract addresses.

Detailed Instructions

Begin by auditing all asset inflow sources that contribute to your protocol's liquidity. This requires analyzing transaction logs from integrated bridges (e.g., Wormhole, LayerZero, Axelar) and canonical bridges of connected Layer 1 and Layer 2 networks. For each asset, you must trace its native chain of origin and the bridge contract used to lock or mint the wrapped version on your protocol's host chain.

• Sub-step 1: Query bridge contract event logs for DepositLocked or TokenMinted events to identify incoming asset transfers. For example, on Ethereum, check the Wormhole bridge contract 0x3ee18B2214AFF97000D974cf647E7C347E8fa585.
• Sub-step 2: Aggregate the original asset value in its native chain's denomination (e.g., ETH on Ethereum, not wETH on Arbitrum) before bridging to avoid double-counting.
• Sub-step 3: Create a mapping table linking wrapped asset addresses on your chain to their canonical origin addresses and bridge intermediaries.

Tip: Use a blockchain indexer like The Graph or Covalent to streamline cross-chain data aggregation, as manual RPC calls can be inefficient.

Detailed Instructions

Establish a deduplication engine that references a shared registry of canonical asset identifiers. This system must recognize when liquidity is sourced from a bridged representation of an asset already locked in another protocol's TVL. The core principle is to count economic value once at its source, not each time it is wrapped or relayed. A common standard is to use the Chainlink CCIP or a similar oracle network to maintain a canonical price feed for the native asset, not its derivatives.

• Sub-step 1: Define a primary key for each asset as [native_chain_id, token_contract_address]. For native ETH, use address 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.
• Sub-step 2: In your TVL aggregation script, before adding a new position, check if the asset's primary key already exists in your tracked liquidity from a different bridge or chain.
• Sub-step 3: If a duplicate is found, only add the position with the highest verifiable lock timestamp to the TVL sum.

codeCopy
// Pseudo-code for duplicate check
function addToTVL(Position memory pos) internal {
    bytes32 assetKey = keccak256(abi.encodePacked(pos.nativeChainId, pos.nativeAddress));
    if (existingPositions[assetKey].timestamp < pos.timestamp) {
        totalTVL -= existingValue;
        totalTVL += pos.value;
        existingPositions[assetKey] = pos;
    }
}

Tip: Collaborate with other major DeFi analytics platforms (DeFi Llama, Token Terminal) to align on a shared anti-double-counting framework.

Detailed Instructions

Not all bridged assets hold equal value to their native counterparts due to liquidity fragmentation and bridge security assumptions. Your TVL methodology must apply a risk-adjusted valuation model. For example, an asset bridged via a less-secure, newer bridge might be valued at a 5-10% discount compared to the same asset bridged via its canonical, audited bridge. This involves sourcing price data and applying a confidence-weighted multiplier.

• Sub-step 1: Categorize each bridge integration by its security model (e.g., externally verified, natively validated, optimistic) and assign a trust score from 0.9 to 1.0.
• Sub-step 2: Fetch the native asset's USD price from a decentralized oracle (e.g., Chainlink 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419 for ETH/USD).
• Sub-step 3: Calculate the adjusted value: TVL_Contribution = (Bridged_Amount * Native_Price) * Bridge_Trust_Score. For a 100 ETH position via a bridge with a 0.95 score and ETH at $3,000, the contribution is 100 * 3000 * 0.95 = $285,000.

Tip: Regularly review and update bridge trust scores based on audits, total value secured, and incident history to keep valuations realistic.

Detailed Instructions

Deploy a synchronized indexing service that polls multiple blockchain networks in parallel to capture the latest state of your protocol's contracts. This system must handle chain reorganizations and RPC node failures gracefully to ensure TVL metrics are consistent and available. Use a message queue (like RabbitMQ) to manage tasks for each chain, ensuring that a delay on one network (e.g., Solana) doesn't block data from others (e.g., Polygon).

• Sub-step 1: Set up individual indexer services for each chain (EVM, Solana, Cosmos, etc.), each subscribing to new blocks and parsing relevant contract events.
• Sub-step 2: Implement a consensus checkpoint—a central service that aggregates the indexed data only after receiving confirmed block headers from, say, 75% of the validator sets for each connected chain.
• Sub-step 3: Store the aggregated, deduplicated TVL data in a time-series database (e.g., TimescaleDB) with a clear schema including timestamp, chain_id, asset_key, raw_value, and adjusted_value.

codeCopy
# Example command to start an indexer for Ethereum
node indexer.js --chain ethereum --rpc wss://mainnet.infura.io/ws/v3/YOUR_KEY --contracts 0xProtocolAddress

Tip: Consider using a decentralized oracle network like Chainlink Functions to fetch and compute cross-chain TVL directly on-chain if your protocol requires it for internal logic.

Detailed Instructions

Transparency is critical for trust in your adjusted TVL figures. Publish a detailed methodology specification that outlines every assumption, data source, and calculation step. This document should be version-controlled (e.g., on GitHub) and updated with any changes. Furthermore, provide public data endpoints (APIs) and on-chain verifiable attestations (e.g., via EAS on Ethereum) of your daily TVL snapshots to allow for independent verification.

• Sub-step 1: Host a static METHODOLOGY.md file detailing asset sourcing rules, bridge trust scores, deduplication logic, and price oracle addresses.
• Sub-step 2: Deploy a public GraphQL or REST API endpoint (e.g., https://api.yourprotocol.com/tvl/history) that returns raw and adjusted TVL time-series data.
• Sub-step 3: Once daily, generate a cryptographic proof (like a Merkle root) of your TVL state and post it to a cheap, durable chain (e.g., Arweave or Ethereum via EAS at 0xA1207F3BBa224E2c9c3c6D5aF63D0eb1582Ce587).

Tip: Engage with third-party auditors (e.g., OpenZeppelin, ChainSecurity) to review your methodology and data pipelines annually, publishing their reports alongside your data.