How to Evaluate Blockchain Network Activity: Fees, Users, Transactions & Validators

By the CoinQuickly Editorial Team

To evaluate blockchain network activity, combine four questions: how much useful work the network processes, who participates and returns, what participants pay, and how independently the network is operated. Transactions, active addresses, fees, and validator counts each measure part of that picture. None is a complete adoption or security score.

Start by checking exactly what a dashboard counts, then compare consistent periods and inspect the composition behind changes. More transactions can reflect consensus votes or repeated failed attempts; more addresses can come from one actor; higher dollar fees can result from a higher token price. A useful assessment explains these alternatives and identifies what additional evidence would distinguish them, rather than converting every rising chart into a claim of growth.

🧭 Key Takeaways - Transaction counts, successful application actions, and transfers are different units. - Addresses and fee payers are observable; unique human users usually are not. - Separate total fees, typical transaction cost, burned fees, operator receipts, and token issuance. - Validator count does not reveal independent operators or the distribution of consensus power. - Compare activity quality, retention, concentration, and reliability alongside headline growth.

📊 Define the network activity you want to evaluate

Blockchain network activity describes recorded operations and participation within a chosen network boundary. That boundary might be a base layer, one application, a rollup, or an ecosystem containing several chains.

A base layer, or Layer 1, supplies a blockchain's underlying execution or settlement system. A Layer 2 processes activity through an additional system that relies on a base layer for specified functions. Its precise security and settlement arrangements must be checked individually.

Before reading a chart, record the network, mainnet versus testnet, date range, time zone, metric definition, and data provider. Also check whether the observation is finalized and whether the provider has indexed all relevant blocks.

A seven-day total should not be compared directly with a 30-day total. Use equal windows, and inspect several consecutive periods to avoid selecting a launch, incentive campaign, or outage as the whole story.

🔗 Transactions: count completed work, not just records

A transaction is a protocol-defined submitted operation. It is not necessarily one payment, one trade, or one person taking one action.

One transaction can contain several instructions or transfers. A batch can settle many payments. A smart-contract interaction—a call to code executed under network rules—can trigger additional internal calls and events. Counting all these records as separate transactions can multiply the same underlying activity.

The Bitcoin developer guide documents transactions with multiple inputs and outputs, including change. That structure is one reason transaction count and payment count differ. A transfer-volume calculation must also handle change and self-transfers rather than interpreting every output as new economic settlement.

Separate system operations, failed attempts, and application activity

Check whether the headline count includes consensus messages, maintenance operations, and failed transactions. Solana's official performance-sample API, for example, distinguishes total transactions from non-vote transactions. That distinction matters when interpreting throughput; non-vote transactions still are not automatically successful human activity.

Useful categories include:

• Included transactions, separated by success or failure where the protocol records that status.
• Consensus or system operations.
• Successful application transactions, under a disclosed classification.
• Instructions, transfers, or user operations, reported as separate units.
• Attempts that never reached the chain, which an explorer may not observe.

An included transaction that fails execution can consume resources and incur charges under the relevant network's rules. It represents workload but does not establish that the intended swap, payment, or application action completed.

Repeated failures may come from automation, congestion, stale prices, or application design. Do not label all failures as spam or remove them without explaining the question the filter serves.

Distinguish throughput from capacity and user experience

Transactions per second, or TPS, is an observed count divided by elapsed seconds. A brief peak, a full-day average, and a laboratory capacity estimate answer different questions.

Also inspect resource use, transaction composition, inclusion delays, finality, and outages. Finality describes the assurance, under a network's rules and assumptions, that a recorded result will not be reversed. Fast initial confirmation is not automatically final settlement.

A network can show high TPS while many attempts fail or while activity is concentrated in a narrow automated strategy. Conversely, batching can improve service without increasing the number of base-layer transactions.

👥 Users: distinguish people, addresses, accounts, and fee payers

An active address is an address meeting a provider's activity rule during an interval. It is not a verified person.

Coin Metrics documents unique active-address counts and notes that definitions depend on network structure. Its documentation also warns that cheap address creation and transacting can make such metrics easy to manufacture. Check whether a count includes senders, recipients, contract addresses, subaccounts, or other participants.

One person can control many addresses. One exchange address can represent many customers. Automated agents can operate many accounts, while shared custody can hide individual participation. Entity clustering attempts to group related addresses, but the resulting entities are estimates rather than a complete user registry.

Fee payers provide another lens: which accounts funded transactions? Yet sponsored transactions can let one payer fund many users, and a shared infrastructure service can consolidate payments. A change in sponsorship arrangements can alter payer counts without a comparable change in end users.

Test persistence with a clearly defined cohort

Retention asks whether a defined group returns. A transparent address-level measure is:

Address retention = addresses in a starting cohort that meet the activity rule in a later window ÷ addresses in the starting cohort.

Specify whether the cohort contains newly observed addresses or all active addresses. These produce different statistics. Do not sum daily active addresses to obtain weekly unique addresses; an address active every day would be counted repeatedly.

Retention can strengthen evidence of recurring participation, but returning bots can also look persistent. Combine it with application distribution, transaction purpose, fee sponsorship, and any incentive schedule.

Automation is not inherently meaningless. Liquidations, arbitrage, and routine settlement can provide services. The relevant question is what the activity does and how dependent it is on subsidies or repeated self-interaction.

💸 Fees: separate demand, affordability, and recipients

Fees measure what the relevant system charges for processing operations. They can help assess willingness to pay, but neither high nor low fees establish network health by themselves.

High fees may accompany demand for limited capacity, costly computation, or an inefficient user experience. Low fees may reflect abundant capacity, technical improvements, subsidies, or weak demand. Compare fees with workload, cost distribution, and completed activity.

Report native units and dollar values separately

Total fees in a native token and total fees in USD answer different questions. If native-token fees remain unchanged while the token's dollar price doubles, dollar-denominated fees can double without an increase in token-denominated expenditure.

For a single fixed illustrative conversion:

USD fees = fees in native tokens × USD price per token.

For a real period containing many payments, a more precise total sums each fee at the chosen contemporaneous price. A provider using a daily average or closing price can produce a different figure; disclose the convention.

The CoinQuickly Converter can help interpret token amounts in another currency. A current conversion is not a reconstruction of historical fee expenditure; historical analysis needs matching prices and timestamps.

Average fees can be dominated by a small group of expensive transactions. Add the median, a range or percentile, and the costs of comparable actions. A basic transfer and a complex contract interaction consume different resources.

Reconcile fees with burn, operator receipts, and issuance

User-paid fees are not automatically revenue received by validators, the protocol treasury, or token holders. Follow the fee path under the network's rules.

Ethereum's official gas documentation distinguishes the burned base fee from the priority fee paid to the block proposer. Solana's fee documentation describes a different distribution structure. These examples show why an analyst must read the protocol rules rather than copy one chain's accounting labels onto another.

Also separate application charges from network fees. A trading application's fee and the transaction's execution fee can be distinct payments. A rollup may charge users while paying execution, settlement, or data-publication costs elsewhere. Gross receipts do not equal profit after these costs.

Token issuance is another separate flow. Rewards funded by newly issued tokens are not the same as fees paid by users. Fee burn may affect supply, but it does not create a direct cash distribution to every holder. CoinQuickly's tokenomics guide explains issuance, burns, circulating supply, and dilution needed to evaluate that relationship.

🛡️ Validators: measure control and reliability beyond the count

A validator participates in consensus under a network's rules. A validator identifier, a physical node, an operator, a staking service, and an independent decision-maker are different things.

One operator may control many validator identifiers. Different operators may share a cloud provider, client implementation, or administrative dependency. Therefore, an increase in registered validators does not establish broader independent control.

Protocol changes can affect counts too. Ethereum's current documentation allows consolidation into compounding validators with larger effective balances. A reduction in validator identifiers can therefore occur without an equivalent reduction in stake or independent operators. Check whether a chart spans such a rule change before interpreting it.

Examine stake distribution and operational dependencies

For a proof-of-stake network, examine active stake by operator or controlling entity, not just the number of keys. State how entities were attributed and what remains unknown. A staking pool, its underlying node operators, and the parties controlling upgrades or withdrawals can represent different layers of influence.

Useful checks include:

• Shares of active consensus weight controlled by the largest identified operators.
• Client-software diversity and common infrastructure dependencies.
• Participation, missed duties, finality delays, and incident history.
• Entry requirements, delegation rules, penalties, and mechanisms for replacing operators.

Ethereum's client-diversity documentation explains how dependence on one software implementation can amplify shared failure risk. Its node documentation also notes that crawlers provide incomplete views and can report different counts.

A concentration coefficient is meaningful only after naming the relevant action, protocol threshold, and entity definition. There is no universal validator-count threshold proving decentralization across all networks. Proof-of-work systems also require a different analysis of miners, pools, hash power, and verifying nodes.

The CoinQuickly Ethereum page supplies market context for ETH. Market capitalization and price do not reveal validator independence; consensus records and documented operator attribution are separate inputs.

🧮 CoinQuickly analysis: headline growth can hide weaker completed activity

Consider a hypothetical network observed across two consecutive seven-day periods. The three transaction categories below are mutually exclusive and exhaustive. They are assumed to be accurately classified solely for this example.

How CoinQuickly analyzed this

These are invented inputs, not observations about an actual chain. Both periods use the same counting rules and address universe. Growth is ending value divided by starting value minus one. Successful application transactions equal included transactions minus system transactions minus failed non-system transactions.

The calculations show:

• Headline transaction growth: 1,500,000 ÷ 1,000,000 − 1 = +50%.
• Successful application transaction growth: 450,000 ÷ 500,000 − 1 = −10%.
• Address growth: 130,000 ÷ 100,000 − 1 = +30%.
• Starting-cohort address retention: 20,000 ÷ 100,000 = 20%.
• Native-token fee growth: 1,100 ÷ 1,000 − 1 = +10%.
• USD fee growth: ($4,400 ÷ $2,000) − 1 = +120%.

The address-retention denominator is Period A's 100,000 addresses. It does not mean that 20% of Period B's addresses returned. Nor do the remaining 110,000 Period B addresses have to be newly created: they could include older addresses inactive during Period A.

CoinQuickly analysis: these observations support headline growth and higher fee expenditure, but not an unqualified claim that successful application activity increased. The increase in USD fees also substantially reflects the assumed token-price change.

There is no basis here to identify humans, detect fraud, measure profit, or conclude that 20% retention is good or bad for every use case. That requires application context and a suitable comparison. The next checks would examine which system operations grew, why attempts failed, and whether participants returned after any incentives ended.

A separate validator-count counterexample

Suppose validator identifiers increase from 1,000 to 2,000, while the three largest identified operators' shares change from 20%, 15%, and 10% to 25%, 20%, and 15%.

The identifier count doubles, but the combined share of those three operators increases from 45% to 60%. This synthetic example demonstrates why a larger count and more concentrated control can coexist. It does not claim any particular attack threshold or describe a real network.

Cross-chain and Layer 2 comparisons need matching units

Different networks allocate and record work differently. Comparing raw counts without examining those choices can reward a counting convention rather than greater adoption.

L2BEAT's activity interface distinguishes transactions per second from user operations per second. Such alternatives can improve the description of batching, but a user operation remains a technical counting unit, not a verified human user or a universal unit of economic value.

Do not add rollup execution counts and the base-layer transactions carrying their batches and describe the result as independent user actions. Define whether the question concerns execution, settlement workload, or ecosystem participation first.

A rollup's sequencer, proof system, data availability, upgrade controls, and settlement arrangements also require separate review. A sequencer orders transactions; its role is not automatically equivalent to a decentralized base-layer validator set. CoinQuickly's crypto risk management framework helps map smart-contract, governance, and infrastructure dependencies that activity charts omit.

🔍 Turn the metrics into a defensible evaluation

Begin with a question about service or adoption, then select evidence that could support or contradict it. For example: “Did recurring payment activity expand without a deterioration in cost or completion rates?” is more testable than “Is this chain healthy?”

Use a consistent review sequence:

1. Fix the boundary. Name the chain, applications, interval, finality convention, and data provider.
2. Reconcile counts. Separate system work, successful transactions, failures, actions, and transfers.
3. Test participation. Examine unique-address definitions, cohort retention, concentration, and sponsorship.
4. Trace expenditure. Compare native and dollar fees, typical costs, recipients, incentives, and issuance.
5. Inspect operation. Assess stake or control concentration, reliability, and common dependencies.
6. Challenge the interpretation. Check upgrades, campaign dates, indexing gaps, and alternative explanations.

A reproducible research note should preserve query filters, block ranges, time zones, fee-price methodology, label versions, and exclusions. If providers disagree, identify the difference before averaging their totals. Unknown bot share or incomplete operator attribution should remain explicit gaps.

CoinQuickly's cryptocurrency comparison framework places this activity assessment alongside network purpose, token economics, governance, and market quality. Usage is one component of that research, not a complete valuation model.

A defensible finding might state that successful application transactions and returning-address participation expanded over equal windows while costs remained stable, with specified limits on human identification and operator attribution. If those pieces diverge, report the divergence. It tells the reader more than a single growth percentage or an unsupported network score.

Disclaimer: The content on this website is for informational and educational purposes only and does not constitute financial or investment advice. The cryptocurrency market involves a high level of risk. Always do your own research (DYOR) before making any decision.