A contract upgrade should strengthen your protocol, not make its TVL vanish overnight. Yet on DefiLlama, that’s what happens for many teams.

Among 400 DeFi protocols analysed, more than half show over a 20% gap between on-chain TVL and DefiLlama data, which was often caused by contract upgrades or migrations.

The issue is adapter failure. When new contracts or logic changes occur, the adapter code that tracks balances no longer aligns, creating a mismatch between on-chain reality and what dashboards display.

This blog explains how DefiLlama calculates TVL, why adapters fail after upgrades, and how to check your protocol’s TVL accuracy.

Let’s get started.

How DefiLlama Aggregates TVL: On-Chain & Off-Chain Methods

DefiLlama aggregates TVL from multiple public sources like blockchain calls, community adapters, and analytics platforms like Dune, The Graph, and Token Terminal to build a unified view of liquidity.

Here are the approaches that DefiLama uses to calculate TVL:

On-Chain Adapters

Each protocol listed on DefiLlama has an open-source Node.js adapter, written and maintained by contributors.

These scripts query token balances, pool reserves, or vault holdings through standard blockchain calls such as:

• balanceOf() for ERC-20 tokens
• eth_getBalance() for native assets

The balances are then priced in USD using Coingecko or DefiLlama’s internal feeds, and summed across vaults and chains.

This on-chain method is transparent, verifiable, and easy to audit.

However, its accuracy depends entirely on how well the adapter tracks current contract addresses and upgraded logic.

Off-Chain Indexers and APIs

DefiLlama also collects data from off-chain sources like The Graph subgraphs and protocol APIs, especially for staking, lending, or liquid restaking protocols where on-chain queries aren’t enough.

Adapters fetch metrics such as totalAssets or totalDeposits from these endpoints to calculate TVL.

For example, Lido and Rocket Pool use subgraphs for staked ETH data, while Curve and Aave rely on APIs for vault snapshots.

This approach improves data consistency across chains but introduces lag when a subgraph or API isn’t updated after an upgrade.

DefiLlama’s TVL may show drops or delays even if on-chain liquidity remains stable.

Integrations from Third-Party Analytics Platforms

To improve coverage and cross-verification, DefiLlama also integrates data from analytics platforms such as Dune Analytics, Token Terminal, and Messari.

These integrations act as secondary data checks, aligning on-chain adapter outputs with community-verified dashboards.

For example:

• Dune dashboards often act as reference queries for verified protocol data.
• Token Terminal and Messari provide context and baseline comparisons for ecosystem-wide liquidity metrics.

While these integrations strengthen data quality, they also increase dependency risks.

Any schema change, delay, or missing update in one external dataset can cause short-term gaps or incorrect TVL representation on DefiLlama.

This multi-source design makes DefiLlama powerful, but also fragile. Each layer of data, from on-chain adapters to external dashboards, needs to stay synchronised.

When a protocol upgrades contracts, redeploys vaults, or changes storage logic, even one outdated source can cause visible inconsistencies across the entire stack.

When TVL drops after an upgrade, it’s rarely about liquidity; instead, it is usually outdated adapters falling out of sync. Here are the contract changes that often cause it.

Common Contract Changes That Break DefiLlama Adapters

When a protocol upgrades its contracts, several moving parts change, such as addresses, logic, storage layout, or indexing sources.

Adapters, however, don’t automatically recognise these changes. They continue to query the old contract structure, creating data mismatches between what’s on-chain and what’s displayed on DefiLlama.

These mismatches often look like sudden TVL drops or spikes, but in most cases, they’re simply adapter breakdowns triggered by one of a few predictable upgrade patterns.

Here are the types of upgrades that commonly break adapters:

New Pools or Vaults Not Added

Many protocols launch new vaults or liquidity pools during upgrades. If the adapter isn’t updated with the new contract addresses, those pools are excluded from TVL calculations, which results in:

Displayed TVL drops instantly, even though on-chain liquidity is untouched.

For example, during upgrades or migrations, DefiLlama often underreport TVL because adapters still query old contracts, causing apparent TVL drops despite stable on-chain balances.

Proxy Storage or Logic Changes

Protocols that use proxy contracts often shift storage layouts or logic implementations during upgrades.

If the adapter still queries old variable slots or outdated functions, it retrieves incorrect or null values and resulting in TVL flatlines or returns zero.

For example, Aave’s proxy upgrade in 2023 caused its adapter to misread totalReserves() until the storage mapping was corrected in the adapter logic.

Version Migrations (v1 → v2)

When protocols maintain both old and new versions temporarily, adapters can double-count balances or miss new deployments entirely.

This happens because adapters often aggregate TVL across all pools without distinguishing versions.

The result: TVL appears inflated or oscillates between values.

For example, Balancer’s migration period briefly showed inflated TVL as the adapter summed balances from both v1 and v2 vaults before the old ones were deprecated.

Custom Logic or Function Updates

Adapters that depend on custom contract functions, such as getTotalPooledEther() or totalAssets(), are more fragile.

If these functions are renamed, replaced, or moved, the adapter call fails silently, which results in: TVL returns zero or fluctuates unpredictably.

For example, Lido’s 2024 upgrade changed internal accounting for stETH, breaking older adapters that still referenced the previous getter functions.

Off-Chain Indexer or API Lag

When adapters fetch data from The Graph, subgraphs, or protocol APIs, any delay in indexer synchronisation leads to incorrect TVL reporting.

This issue is especially common for multi-chain deployments where data propagation takes hours and results in: DefiLlama shows delayed or incomplete TVL updates.

For example, Curve’s cross-chain deployment on Arbitrum showed a 24-hour lag in reported TVL after migration, traced back to an outdated subgraph endpoint.

Adapter breakdowns are not rare errors, but they are part of a fast-moving ecosystem where upgrades often outpace data pipelines.

When contracts evolve faster than adapters, dashboards no longer show the real state of liquidity.

The good news is that these mismatches are easy to fix once the root cause is identified and can usually be fixed within hours.

Knowing why adapters break is one part of the equation; the other is learning how to detect when the data stops matching the chain.

On-Chain TVL Verification: How to Tell True Liquidity Changes

After upgrades, sudden TVL drops can be misleading.

And most protocols that experience a sudden TVL drop after an upgrade face the same question: Did the liquidity actually move, or did the adapter just stop tracking it?

The answer lies in a few quick on-chain checks that separate real events from reporting errors.

Step 1: Verify TVL on-Chain in Minutes

The first step is to confirm whether your TVL drop reflects real liquidity movement or a data mismatch.

You can verify this directly on-chain in under five minutes.

Here’s a sample query that calculates on-chain TVL by summing token balances and comparing them with DefiLlama’s reported values.

Interpretation:

Once you’ve run the query, here’s how to read the results:

• Stable token balances and prices are likely an adapter desync, often caused by missing contract addresses, outdated logic, or a lagging subgraph/API.
• Falling on-chain balances indicate a real liquidity movement such as withdrawals, migrations, or liquidations.
• Stable balances but dropping USD value is usually a price fluctuation, not an adapter failure.
• Balances missing for new v2/v3 addresses. The query’s scope is incomplete, not the adapter itself.

To confirm, calculate the vTVL Discrepancy Ratio:

Discrepancy = |DefiLlama_TVL - Onchain_vTVL| / Onchain_vTVL

A sustained difference of 20% or more over a week is a strong indicator that the adapter is out of sync.

Step 2: Pinpoint the Adapter Failure Mode (Address, Logic, API)

Once you know the issue lies in the adapter, the next task is to find exactly where it broke.

The DefiLlama Adapters GitHub repository provides clear patterns that map symptoms to causes.

You can also search existing reports on github.com/DefiLlama/DefiLlama-Adapters/issues to see if the problem is already known.

These small tests usually reveal the fault within minutes, whether it’s a missing pool, outdated logic, or a lagging indexer.

Step 3: Set Up Automated vTVL Monitoring with Alerts

Instead of waiting for discrepancies to reappear, you can automate TVL verification with a simple Dune dashboard.

This turns manual debugging into a continuous monitoring process.

vTVL dashboard template:

Set alert rules:

• Trigger alert when |DefiLlama_API_TVL – vTVL| > 15% for 3+ hours
• Send notification to Slack/Discord with protocol name, block height, and adapter commit hash

Result: You’ll know within minutes if an adapter desynchronizes or an endpoint lags, long before your community notices a TVL anomaly.

By following this, you will get to know whether your adapter has failed or not:

Verify → Pinpoint → Monitor

Through this, teams can maintain accurate, real-time TVL visibility across every upgrade. More importantly, it builds trust.

It not only prevents panic over false drops but also strengthens data integrity across the ecosystem.

In DeFi, credibility isn’t built by dashboards; instead, it is built by verifiable data that matches the chain.

Build Upgrade-Proof TVL Systems (Why Verifiable Data Matters)

Adapter failures remind us that in DeFi, visibility can’t depend on dashboards alone. Real transparency comes from data that reflects the chain, not just what’s reported by it.

As protocols evolve, maintaining verifiable TVL pipelines isn’t optional; it’s essential for trust, governance, and credibility.

Teams that monitor, verify, and update their adapters regularly will always stay aligned with the truth that matters most, the one on-chain.

At Lampros Tech, we help protocols build verifiable TVL systems that stay accurate through upgrades and multi-chain expansions.

Our data experts ensure your visibility remains as reliable as your contracts, from adapter updates to automated vTVL monitoring.

Explore our Data Analytics page or book a call to make your protocol’s metrics verifiable, transparent, and upgrade-proof.

Astha Baheti

Growth Lead

Astha Baheti is the Growth Lead at Lampros Tech, a Blockchain development company helping businesses thrive in the decentralised ecosystem. With an MBA in Marketing and hands-on experience in digital marketing and content strategy, she brings expertise in crafting clear, impactful communication that aligns business goals with audience needs. At Lampros, Astha focuses on translating complex Web3 concepts into accessible narratives that drive engagement and awareness.

CONNECT ON:

See more

See more