For quick definitions of key terms used in this guide, see the Crypto Dictionary. Browse the full course here: Fundamental Analysis Hub.
On-chain metrics are public data points drawn from blockchain activity or other observable crypto-system behaviour. They can help test whether a crypto project shows real activity, credible usage signals, security awareness, and operational resilience. But they must be handled carefully. A dashboard number is not proof. You need to know what the metric measures, whether it fits the project category, whether the source and timeframe are clear, and whether incentives, bots, spam, or short-lived campaigns may be distorting the evidence.
What Are On-Chain Metrics In Crypto?
On-chain metrics are public data points drawn from blockchain activity or other directly observable crypto-system behaviour.
At a basic level, they help show what is happening on a network or protocol without relying only on marketing language, team claims, or outside-support announcements. They may include transaction patterns, wallet activity, fees, liquidity, contract calls, validator concentration, and security-related signals.
That is why on-chain metrics matter in Fundamental Analysis. They can help test whether the project’s story has public evidence behind it. But public metrics are evidence inputs, not automatic proof.
What Counts As Public Evidence In Crypto Fundamental Analysis?
Public evidence in crypto includes observable data that helps examine project claims through public activity, usage patterns, security context, or maintenance signals.
Useful evidence categories may include activity signals, usage signals, security signals, development-linked public data where relevant, and category-specific metrics.
Public evidence may include transactions or transfers, contract-call activity, fees, liquidity, TVL where relevant, volume where relevant, bridge flows, validator or governance concentration, exploit history, audit trail, and public maintenance or upgrade activity.
Documents show what the project says. Outside support shows what others may be doing around it. Public evidence helps show what can be observed directly.
Why Public Metrics Matter After Verifying Support Claims
Lesson 6 taught how to verify whether outside-support claims are real, current, material, and relevant. Lesson 7 now asks a different question: even if those support claims are real, what does the public evidence show?
Outside support can improve the story without proving real activity. A real partner, a respected backer, or a valid integration still does not prove that users are active, that the product is being used in a meaningful way, or that the project is resilient under pressure.
Used properly, public metrics can strengthen or weaken the research view. Used badly, they can create false confidence from noisy dashboards and misjudged spikes.
How This Lesson Fits Into The FA Hub Course
Lessons 4 to 6 moved through documents, team quality, and outside-support verification. Those lessons help inspect what the project says about itself and what external credibility signals may or may not support it.
Lesson 7 then asks whether there is public evidence that the project is active, used, secure enough to monitor seriously, and resilient enough to deserve deeper attention.
Lesson 8 comes next because public metrics still do not settle the adoption question on their own. They may show visible activity, direction of use, or capital presence, but Lesson 8 is where you judge whether that activity represents meaningful adoption and real-world use-case strength.
Activity Signals, Transactions, Transfers, And Contract Calls
Activity signals are usually the first public layer people notice. These may include transaction counts, transfer counts, contract calls, bridge flows where relevant, and other visible forms of network or protocol activity.
These signals can help show visible activity, direction of use, whether claims have observable support, and whether activity is rising, flat, or weakening.
But activity signals need context. A high transaction count is not automatically impressive. It may reflect real usage, low-cost spam, bots, incentive-driven behaviour, or category-specific behaviour that does not map cleanly to user quality.
Usage Signals, Wallets, Fees, TVL, Volume, And Liquidity
Usage signals are often treated as stronger than simple activity counts because they may show economic weight or ongoing participation.
These may include wallet activity, fees, TVL where relevant, volume where relevant, and liquidity where relevant. Used carefully, these metrics can show relative network or app activity, capital presence, fee generation where relevant, and whether activity appears to carry economic weight.
But the same warning applies here. Active wallets do not automatically represent real users. Volume does not automatically represent healthy demand. TVL does not automatically represent durable product use. Liquidity present during rewards campaigns may not last.
Security Signals, Audits, Exploits, Validators, And Resilience
Security evidence and resilience matter because visible activity is not enough if the system is fragile.
Relevant public security and resilience signals can include audits, exploit history, validator or sequencer concentration, governance or upgrade controls, bridge or custody risk, bug bounties and disclosures, incident response, and public maintenance behaviour.
These signals help reduce uncertainty only when they are current, relevant, and tied to the project’s actual risk model. Security evidence matters, but it should not be treated as a magic stamp.
Why Category Fit Matters When Choosing Metrics
A metric is useful only when it helps answer the right question for the project category.
Different crypto categories require different metric emphasis. Chains may need transaction patterns, fees, and validator distribution. DeFi protocols may need TVL, liquidity, volume, and fee generation. Bridges may need route usage, security incidents, and maintained flows. Wallets, infrastructure, gaming, social crypto, or RWA projects each need their own relevant evidence layer.
This is why dashboard discipline must always begin with category fit.
| Project Category | Useful Evidence | Research Warning |
|---|---|---|
| Chain | Transactions, fees, validator distribution, app activity. | Low-cost transactions can exaggerate apparent demand. |
| DeFi | TVL, liquidity, volume, fees, retention after rewards. | TVL can leave quickly when incentives change. |
| Bridge | Route usage, flows, liquidity, incidents, security controls. | Bridge activity can be convenience-driven rather than durable preference. |
| Wallet Or App | Repeat use, active wallets, transaction quality, user retention where visible. | Wallet counts can be inflated by campaigns or one-off actions. |
What Public Metrics Can Show
Public metrics can show visible activity, direction of use, relative network or app activity, liquidity and capital presence, fee generation where relevant, TVL where relevant, transaction or contract-call patterns, bridge flows where relevant, validator or governance concentration, audit or incident context, public maintenance or upgrade activity, and whether claims have observable support.
That is valuable. Public metrics help test whether the project’s claims are at least partly visible beyond its own documents.
What Public Metrics Cannot Prove
Public metrics cannot prove real adoption by themselves, user quality, product-market fit, token value capture, long-term demand, team honesty, partnership quality, security by themselves, decentralisation by themselves, future performance, that activity is organic, or that a project is undervalued or safe.
A metric can strengthen a view, weaken a view, or expose a contradiction. It rarely settles the full investment case by itself.
Incentives, Botting, Spikes, And Distorted Activity
High activity is not always strong evidence. Activity needs context, cost, persistence, and category fit.
Distorted or low-quality activity may include bot-like spikes, airdrop farming, wash-like behaviour, short-lived incentive bursts, very low-cost spam transactions, TVL that appears only during reward campaigns, volume without meaningful users, active addresses that do not represent real users, activity unrelated to the stated use case, or one metric rising while supporting metrics weaken.
Useful activity often shows sustained behaviour over time, consistency across more than one relevant metric, some economic weight where relevant, repeat participation, category-relevant transactions, and signals that match the project’s claim.
Dashboard Discipline, Source, Context, And Currentness
Dashboards are tools, not conclusions.
Before trusting any metric, ask what the metric is actually measuring, what the source is, whether the data is current, whether the metric is chain-specific or app-specific, whether the timeframe is clear, whether the methodology is explained, whether it can be cross-checked, whether it is relevant to the project category, and whether incentives, bots, spam, or low-cost activity may distort it.
Good dashboard discipline means understanding both the metric and its limitations before using it as evidence.
Stronger Public Evidence Versus Weak Public Evidence
Stronger public evidence often shows sustained activity over time, consistency across more than one relevant metric, category fit, some economic weight where relevant, public signals that match the project’s stated purpose, security or resilience evidence that is current and tied to the risk model, and observable support for project claims without obvious distortion.
Weak public evidence often shows one isolated metric with no support from other signals, strong-looking activity that disappears when incentives fade, unclear source or timeframe, category mismatch, heavy distortion risk, stale dashboards or unexplained methodology, and data that sounds impressive but does not answer the right research question.
| Evidence Layer | Stronger Signal | Weaker Signal |
|---|---|---|
| Activity | Sustained category-relevant activity across time. | One-off spikes, cheap spam, bot-like behaviour, or campaign-driven bursts. |
| Usage | Usage with economic weight, repeat behaviour, or meaningful retention. | Active wallets, TVL, or volume with weak context and no durability check. |
| Security | Current security evidence tied to the project’s real risk model. | Old audits, vague security language, or ignored incident history. |
| Source Quality | Clear source, timeframe, method, and cross-check path. | Stale dashboards, unclear methodology, or screenshots without context. |
A Compact Worked Demonstration
Imagine a fictional project called Northbridge Relay, a bridge.
Three public signals matter. First, bridge transfer count over the last 90 days is useful as an activity signal because it shows visible route use over time. Second, retained liquidity after incentives faded is more useful than headline TVL because it starts to show whether capital remains once rewards normalise. Third, a recent security review and incident-response note add resilience context, but they do not prove perfect safety.
One distortion risk remains: some route activity may still be convenience-driven rather than durable user preference. One stronger public-evidence signal is sustained route use after the incentive peak. One unresolved signal is whether that route use translates into meaningful adoption quality rather than just operational convenience.
This is the right scale for Lesson 7. It uses category-fit metrics, identifies a distortion risk, shows one stronger and one weaker signal, and hands the next question into adoption analysis.
Common On-Chain Metrics Mistakes To Avoid
Common mistakes usually come from treating dashboard data as stronger than the evidence allows.
A screenshot can show data, but it does not explain source quality, timeframe, method, or distortion risk.
Activity can be visible without proving repeat use, durable demand, or strong user quality.
A useful metric for a DeFi protocol may be weak evidence for a bridge, chain, wallet, or infrastructure project.
One metric can be distorted. Better evidence usually comes from several relevant signals pointing in the same direction.
Airdrop farming, rewards campaigns, low transaction costs, and spam can all distort activity quality.
The correction is simple: ask what the metric measures, why it matters, and what it still cannot prove.
Practical Public-Evidence Checklist
Use this checklist before carrying public metrics into the adoption lesson.
Record whether the project is a chain, DeFi protocol, bridge, wallet, app, infrastructure project, gaming project, social crypto project, RWA project, or another category.
Select the activity signal that best fits the project category, such as transactions, transfers, contract calls, or bridge flows.
Record the most relevant usage signal, such as fees, liquidity, TVL, volume, active wallets, or repeat interaction.
Write down where the data comes from, what period it covers, and whether the method is clear enough to trust.
Flag botting, incentives, spam, short-lived campaigns, low-cost activity, or any mismatch between the metric and the use case.
Carry one clear question into Lesson 8 about whether the visible activity reflects meaningful adoption and real-world use-case strength.
This keeps public-evidence review practical and prevents dashboard noise from driving the whole research view.
What To Record Before Judging Adoption Quality
Before Lesson 8, make sure you can state which public signals are actually relevant to the category, which ones look strong, which ones look noisy, what the main distortion risk is, and what the public evidence still cannot prove.
That lets the adoption lesson start from an honest evidence base instead of raw dashboard enthusiasm.
How This Prepares You For Adoption And Use-Case Analysis
Lesson 7 helps test whether the project has observable activity and usable public evidence. Lesson 8 then asks the deeper question of whether that activity reflects meaningful adoption, real users, repeat use, and a real-world use case.
So this lesson is the bridge between observable public evidence and real adoption judgement.
Discussion