DefiLlama listing: why project TVL is calculated incorrectly
Public aggregators calculate locked value not from your accounting, but from on-chain events: the adapter walks contract addresses, parses calls, and sums pool balances.
If the adapter doesn't know some pools, doesn't understand derivative instruments, or adds them at face value together with the underlying asset, the figure diverges from the actual state of the contracts. From the outside this looks like incorrect TVL, although the contracts operate normally.
Typical causes of metric discrepancy are unverified code, absence of a public interface description and addresses in the repository, and a multichain configuration where part of the liquidity lives in another network and isn't included in the sum.
A separate story is double counting: LP tokens and staking receipts are counted both as a standalone asset and as collateral, which inflates the metric, and after an adapter fix it drops sharply.
The consequence of such an error is not cosmetic. The project fails protocol verification, drops out of comparisons and rankings, and integrators and analysts build solutions on a distorted picture. A TVL drop on the chart reads as an outflow of funds, even when the liquidity is in place.
Next we break down how the DefiLlama listing works: what the aggregator requires from contracts, how verification works, and what reconciliations close the metric discrepancy.
What analytics setup delivers: reconcilable TVL and flows
Correct TVL is not a single number from a dashboard, but a reproducible calculation.
It includes the value of locked assets across all networks, a single price source at snapshot time, decimal handling, and exclusion of double counting — when the same funds go into both a pool and a derivative instrument based on it.
We describe the formula and fix it in the adapter configuration: DefiLlama calculates protocol metrics using it, not its own internal heuristics.
Then comes indexing. The subgraph collects contract events, the calculation is rebuilt on schedule, and Dune exports catch up to the same data snapshot.
Manual tables go away: the value updates itself, not at the end of the month by an analyst, and looks the same in our dashboard, in Dune, and on aggregators.
Capital flows are visible as a separate metric: daily inflow and outflow, net by pools and networks, breakdown by address cohorts. It distinguishes organic growth from one-off injections for an incentive program — and shows outflow in advance before it turns into a collapse.
Data reconciliation closes the last gap: if the discrepancy between sources exceeds a threshold, a check triggers and you can see where accounting was lost. The class of manual reconciliation errors — duplicated pools, stale prices, missed events — simply stops occurring.
Ways to present data: subgraph, dashboard, manual report
The data presentation method is chosen by the metric consumer and update frequency: accuracy and maintenance volume depend on it. Below are three workable options with their boundaries.
| Option | When suitable | Limitations |
|---|---|---|
| Subgraph | Need programmatic output: own aggregation logic, queries from an interface, bot, or calculation script | The index lags the chain and requires rechecking after a reorg; the schema and mappings are maintained with every contract change |
| Public dashboard | Need external reach and a quick start: protocol aggregates without your own infrastructure | The calculation methodology is set by the platform, nonstandard metrics express poorly, and history depth is limited by the source |
| Manual reporting | The metric is unique or calculated once from closed data | Reproducibility falls, updates depend on a person, and the methodology has to be fixed by procedure |
In practice methods are combined: the subgraph covers regular metrics, the dashboard works as an external showcase, and the manual report is for rare slices.
For listing on DefiLlama, a verifiable source with open methodology is needed — more often a subgraph that returns the volume of locked funds by protocol addresses.
Work stages: from contract audit to schema handover
A public dashboard is a showcase behind which stands a validated accounting schema. An error in event markup produces a beautiful number that falls apart at the first external check.
So we proceed sequentially: from contract analysis to documentation by which the team maintains analytics without us.
- Data audit. Analyze contracts, pools, and events, and record which values are extracted from the chain directly and which are derived from several sources.
- Accounting schema. Describe entities, fields, and relations: how we calculate TVL, where we exclude double counting, and by which keys we aggregate addresses and tokens.
- Collection setup. Raise event indexing and scheduled recalculation, and separately account for block gaps and state rollbacks.
- Metric validation. Reconcile the calculation on historical data and with independent sources; explain discrepancies to zero, not write them off as indexing lag.
- Publication. Prepare the listing in DefiLlama and the dashboard pages so the calculation methodology is visible to the user.
- Update procedure. Fix the recalculation frequency, alert thresholds, and the procedure for data desync.
- Documentation handover. Give schemas, accesses, queries, and instructions — maintenance is not tied to us.
What you receive: schemas, rules, procedures
Analytics ends not with a beautiful dashboard, but with a set of artifacts by which the team works further without us. We hand over everything to the project repository: each document has an owner, a version, and a link to a specific data source.
- Source and entity schema — which contracts, pools, and tokens enter the calculation, how they relate, and where each number comes from.
- Collection configurations — indexing parameters, address lists, and event filters; the configs are in the repository and deployed with one command.
- Access delineation rules — who sees raw data, who changes configurations, and who approves publication of metrics externally.
- Metric descriptions — the formula for each indicator, including TVL: what we count (locked assets, staking, borrowed positions) and how we account for prices.
- Team instruction — how to connect a new pool or network, where to view rebuild logs, and what to do in case of discrepancy with an external dashboard.
- Update procedure — rebuild frequency, validation window, and the procedure for rolling back to the previous snapshot on failure.
- Publication checklist — a set of checks before sending data to DefiLlama: freshness, completeness, and match with on-chain data.
A month after handover, the team handles typical tasks itself: add a network, recalculate a metric, extend access — without contacting us.
Case: how project metrics were brought to a single value
Before
The project showed three different values of locked funds: the internal dashboard calculated from its own snapshots, Dune queries from their own samples, and in the DefiLlama listing the figure lagged by a day.
The analyst reconciled discrepancies manually once a week, and some operations didn't enter the sample at all — large deposits and withdrawals via multisig were lost at an intermediate step. TVL dynamics looked jagged, and it was impossible to distinguish real outflow from indexing lag.
What changed
The subgraph became the single source: contract events are indexed with block number binding, and balance recalculation uses one formula for the dashboard, Dune, and the external listing.
We added amount reconciliation on every update and a separate check for operations that were previously missed — pass-through transfers and transfers with multiple tokens in one transaction. Implementation took six weeks from contract access.
Project result
The discrepancy between internal dashboards and the listing is gone: values match to the last digit, and updates are automatic.
TVL dynamics for the first time gave a picture showing the cause of outflow — not "the number fell" but which pool and in which period withdrew funds.
Manual reconciliation disappeared from the analyst's tasks: the time previously spent on reconciling reports went to metric analysis.
Is DefiLlama listing needed if the project has its own dashboard?
Your own dashboard answers internal questions: where volume dropped, which pool pulls liquidity, and what's happening with emission and collateral.
It doesn't provide external comparison — numbers from a closed dashboard have nothing to verify against, and the project simply doesn't appear in industry reviews.
Listing on DefiLlama is an independent point of reconciliation, not a second dashboard. The platform calculates TVL by a unified methodology, breaks it down by networks and pools, and stores a history of state snapshots that cannot be rewritten retroactively.
Analysts, integrators, and aggregators take numbers from there — for them your dashboard is an unconfirmed source.
Discrepancies are usually not in the project's favor: your own dashboard often counts staked positions and LP tokens twice or doesn't see some contracts. The public metric then reads as a refutation of your own reports, though the error is in the accounting methodology.
Therefore the adapter and subgraph describe contracts explicitly: which call we read, how we calculate pool share, and what we do when a contract updates.
Not everything needs to be exposed. Retention, funnel, and position distribution have no public meaning. Implementation priorities are: first correct TVL accounting and history, then Dune dashboards for specific questions, and only then public metrics around them.
If you doubt whether listing is needed with a live dashboard, describe the task: we'll look at where your methodology diverges from the public one, and come back with an estimate and a plan.
Common technical questions on metric accounting
Metrics on blockchain data almost always differ between platforms: different snapshot moment, different interpretation of assets, and different address list in the sample. Below are common questions asked at analytics contour acceptance, and substantive answers.
Why doesn't our TVL match DefiLlama data?
Usually it's methodology: snapshot moment, treatment of locked and staked assets, and the list of contracts. We fix the methodology in a document and reconcile each discrepancy.
We already have our own contour deployed — is it compatible?
We connect to the existing storage and indexer without breaking them: reuse already collected data and add missing metrics and reconciliation.
What to do after contract updates?
Data rebuild is a routine operation: the address or event signature changes, and indexing of the affected block range runs again. We preserve history, and values before and after the update are comparable.
Can metrics be calculated from closed data?
Yes: the contour is deployed in your perimeter, and only the aggregates you decide to show go outside.
What is included in support after handover?
We monitor indexing health, update methodologies when the protocol changes, and add new metrics. Rebuilding and discrepancy investigation are part of regular work.
Let's discuss the task: reconcile metrics and propose a work plan
For the evaluation to be substantive, not "by feel," the input needs initial data: contract addresses and network, a description of how locked value is currently calculated, and links to existing dashboards or a subgraph, if any.
This is enough to understand the indexing scope and see in advance where numbers in your reporting diverge from what is read from the blockchain.
During the review we clarify what cannot be read from code: which assets to include in TVL, how to avoid double counting LP positions, whether a breakdown by networks and pools is needed, and how to account for staking and locked tokens.
Separately we discuss the requirements for publication in DeFiLlama and who is responsible for maintenance edits after listing — the adapter will have to be updated on contract upgrades.
Based on the review results we return with specifics:
- estimate — scope of work and effort broken down by stages;
- work plan — from contract audit and accounting model to application submission and metric verification;
- timelines with checkpoints and a list of dependencies on your side;
- list of accesses and data without which start is impossible;
- TVL calculation scheme: which calls we read, what we aggregate, and what we exclude;
- indexer and adapter configuration deployed separately from your production contour;
- support procedure: how discrepancies are checked after release and upgrades.
Describe the task in two or three paragraphs and attach what has already been collected — we'll return with an estimate, work plan, and stage composition.