Defilama comparison is a multichain TVL audit with explicit coverage limits

Defilama comparison is a review of whether each DefiLlama total uses the same contracts, chain mapping, timestamp and inclusion policy. DefiLlama derives total value locked from open-source adapters and values tracked balances in US dollars, so apparent gaps reflect both deposited token quantities and asset prices. Use its rankings only after matching core TVL, staking, pool2, borrowed balances and bridge treatment across every chain in the set.

Coverage gaps that reverse a TVL ranking

DefiLlama coverage gaps decide a ranking whenever one adapter omits a deployment, asset class or historical interval from the compared set.

Each protocol adapter queries balances or contract state and assigns them to named chains. New TVL adapters must compute from blockchain data, which makes the calculation inspectable and supports historical calls when archive state exists. A missing deployment therefore produces a one-chain coverage hole rather than evidence of zero deposits. Check the protocol record’s chain list, adapter module and start metadata before ranking a multichain protocol. The comparison becomes complete only when every material deployment enters the same scope. That distinction matters before any ranking is published.

Protocol families create a second mismatch. Aave V3 can expose separate chain rows for Ethereum, Arbitrum One and Base, while a parent record can aggregate a wider family. An Ethereum-only child should not face a multichain parent in the same column. Match the exact product version first, then roll its chain rows into one family total.

Price coverage changes the dollar result even when token balances stay fixed. DefiLlama normally maps tokens to CoinGecko prices and uses an onchain method for assets without that mapping, commonly pool weights from a liquid Uniswap V2 market. A useful Defilama comparison stores raw token quantities beside USD totals. The ranking changes when a material asset gains a valid price path or loses one.

DefiLlama, Dune, Token Terminal and L2BEAT serve different comparisons

DefiLlama fits broad protocol TVL comparisons when its published adapter scope matches the question, while each alternative changes the unit of analysis. Dune exposes raw and decoded blockchain tables for custom SQL, including EVM data and Solana instructions. Token Terminal standardises daily financial metrics with project-specific definitions. L2BEAT measures rollup value secured across three classes: canonically bridged, natively minted and externally bridged. Choose the platform whose metric boundary matches the decision.

Metric boundaries behind the headline TVL

DefiLlama’s TVL boundary decides whether two displayed totals represent comparable deposits, optional components or different layers of onchain value.

Deposits and borrowed liquidity

Core TVL values tokens that users deposit into a protocol’s tracked contracts. DefiLlama separates four useful scopes: core TVL, governance-token staking, pool2 liquidity and borrowed value. For Aave V3, deposited collateral remains part of core TVL while outstanding loans appear as borrows. For Uniswap V3, pool reserves supply the locked balances. Mixing any optional scope into only one row breaks the comparison.

Within one protocol, an adapter should avoid counting a deposited asset and its receipt token twice. Across protocols, composability produces another layer. A user can supply WETH to Aave V3, borrow USDC and place that USDC in Uniswap V3. A chain sum then records value held in both contract systems. That sum measures deployed DeFi positions, not unique external capital.

Chain-level exclusions

Chain TVL applies additional boundaries after protocol adapters return their values. Those exclusions matter most when comparing Ethereum with Solana or an Ethereum rollup.

Native staking

DefiLlama excludes native token staking and bridge TVL from chain TVL, while liquid staking stays excluded by default. Validator stake in ETH, SOL or ATOM therefore does not raise the standard DeFi chain total. Lido remains visible as a liquid staking protocol, yet its category treatment must match across every chain row.

Bridge balances

Bridge projects retain their own TVL records, but those balances do not contribute to either origin-chain or destination-chain TVL. Funds inside Safe smart accounts and Argent wallets also sit outside protocol TVL. These rules prevent custody location from silently replacing protocol usage. The boundary changes only when the analyst deliberately selects another component policy for every chain.

A five-stage audit for multichain coverage

A DefiLlama multichain audit becomes reproducible when five ordered stages lock scope, identity, time, composition and reconciliation before interpretation.

Run the stages in order because a late arithmetic check cannot repair an earlier identity mismatch. One written metric definition governs the full dataset, one canonical family controls aggregation and one timestamp fixes valuation. Any unresolved alias or component stops the ranking. This sequence also creates a compact record that another analyst can repeat without reconstructing dashboard state from memory.

All five stages must pass before the ranking carries analytical weight. Preserve the adapter slug, chain key, timestamp and inclusion flags with the exported values. If a protocol changes versions during the selected period, split the series at that boundary and reconcile both sides. The decision changes when the new adapter preserves the same contracts and accounting policy across the migration. For a worked version, see Defilama explainer.

How should chain and token identities be normalised?

Chain and token identities should use canonical network identifiers and contract or mint addresses before any DefiLlama values enter a comparison.

Ethereum Mainnet uses chain ID 1, OP Mainnet 10, BNB Smart Chain 56, Polygon PoS 137, Base 8453, Arbitrum One 42161 and Avalanche C-Chain 43114. These identifiers prevent a short label such as "Ethereum" or "Arbitrum" from absorbing a test network or another deployment. CAIP-2 adds a namespace when a dataset spans EVM and non-EVM systems. Solana needs its canonical network name and program or mint address because it has no EVM chain ID.

Token normalisation requires the same discipline. ERC-20 makes the decimals field optional, so an analyst must read the token contract rather than assume precision from the ticker. Native USDC uses 6 decimals, which makes one unit equal to 10^6 base units. WETH uses 18 decimals, making one unit equal to 10^18 wei. Solana SPL Token mints store their own decimal setting.

Contract identity also separates native USDC from bridged variants and unrelated assets that reuse a symbol. Map each address to its chain, decimals and price key before summing balances. The grouping rule changes only when two representations carry the same economic claim and the chosen methodology explicitly consolidates them.

Time alignment separates market repricing from deposited assets

DefiLlama time series support a fair comparison only when every chain uses the same snapshot and the same valuation policy.

The historical chain endpoint excludes liquid staking and double-counted TVL, so its series should not join a dashboard export with different toggles. Freeze one Unix timestamp, resolve the closest available block for each chain and retain the price timestamp. DefiLlama TVL updates hourly, while a cached page can trail the API by up to 1 hour. A 1-day, 7-day or 30-day TVL change still combines balance movement with USD repricing. Revalue both endpoints with one price set when the decision concerns deposits rather than market movement.

An indexed comparison answers a different question. Set every series to 100 at the opening snapshot, then track proportional movement instead of absolute dollars. Pair that chart with net USD inflows, which values day-to-day token balance changes rather than the whole stock. Absolute TVL remains the correct view when the decision concerns covered capital, while the indexed view suits relative direction.

Adapter metadata resolves the remaining edge cases

DefiLlama adapter metadata resolves edge cases when a chart gap reflects code capability, token substitution or a known protocol event.

An adapter has three practical layers to inspect: its dependencies, balance-calculation function and exported metadata. The time-travel flag defaults to true, while the misrepresented-tokens flag defaults to false. A start value sets the earliest supported timestamp, and hallmarks label events that materially changed TVL. Historical tests accept two input forms, a Unix timestamp or a date string. Those fields explain why one chain backfills cleanly while another begins at integration.

Git history then shows when contracts, chain keys or methodology changed. Archive-node requirements explain failed historical calls, while a live registry dependency limits old-state reconstruction. CoinGecko mappings and liquid Uniswap V2 pools clarify unusual price paths. Escalate the difference to adapter code when balances disagree after the same scope, identities, timestamp and prices have already reconciled.

Still have questions?