On-Chain Activity: Separate Addresses, Bots and Paying Users

A rising active-address count does not establish that a blockchain application gained the same number of people. Addresses, transactions, automated programs and paying customers measure different things. The useful research question is whether sustained activity represents demand for a service, and how much uncertainty remains in identifying its participants.

This guide uses hypothetical figures to demonstrate an audit. It does not publish a current ranking of chains or label any specific project fraudulent.

Define the event before counting the participant

An active-address metric might count senders, recipients or both during a day. It might include failed transactions, contract accounts, internal calls or only successful top-level transactions. Two dashboards using the same label can therefore report different totals without either containing an arithmetic error.

Write down the chain, contract set, observation window, timezone and inclusion rule. Specify whether activity means signing a transaction, receiving an asset, interacting with a selected application or paying for a completed service. Preserve the query and its version so that another analyst can repeat the measurement.

An address is not a unique person

Ethereum’s account documentation distinguishes externally owned accounts from contract accounts. The distinction describes how accounts operate; it does not identify a human owner. One person can control several accounts, while a service can aggregate many customers through shared infrastructure.

For illustration, imagine 1,000 active addresses. If one operator controls 400 of them, the count cannot be reported as 1,000 independent people. Conversely, an exchange or custodial application can serve many customers through a small number of visible addresses. Public chain data alone may not reveal either mapping.

Account clustering can generate hypotheses, but shared funding sources, timing or transaction patterns are not conclusive ownership proof. Explain the assumptions and avoid presenting inferred identities as verified personal information.

Separate automation from economic value

Automation is not automatically fake use. Market-making, arbitrage, liquidations and recurring payments can deliver useful services through software. The analytical task is to distinguish the activity’s purpose and cost from a claim about human adoption.

Repeated transactions with similar timing, values or counterparties can justify further investigation. They do not establish intent on their own. Incentive farming, legitimate testing, scheduled business payments and automated trading can produce superficially similar patterns.

Report observed behavior first: for example, a small group submitted most transactions or activity stopped when rewards ended. Describe the interpretation separately and state what additional evidence would confirm it.

Test transactions against completed outcomes

Ethereum’s transaction documentation explains the records used to request account actions. A submitted transaction is not necessarily a successful customer outcome. Review execution status and the application’s relevant events rather than counting every attempt as a completed purchase.

Suppose a fictional application records 10,000 attempts, of which 8,000 succeed. Among successful events, 5,000 distribute promotional rewards and 3,000 purchase a service. These categories answer different questions. Counting all 10,000 as paid customer transactions would overstate the evidence.

Deduplicate retries using a documented rule. Keep failed attempts visible as a reliability measure, while separating them from completed service use. A low success rate can matter even when the headline activity count rises.

Follow retention and who bears the cost

Compare cohorts across repeated periods using the same definition. Ask whether accounts return after an initial campaign and whether customers pay fees or a sponsor absorbs them. Subsidized activity can be useful during onboarding, but its economics differ from repeat purchases at a sustainable price.

Do not infer loyalty from one daily total. Show the number of new, returning and inactive accounts, acknowledge that account counts remain imperfect proxies, and check whether a few participants dominate fees or transaction value.

Use several dimensions together: completed service events, customer payments, repeat activity, concentration, failure rates and incentives. None alone proves that an application has durable demand.

Keep token-market evidence separate

The OrangeX markets page describes available trading markets. Exchange volume and token price changes are market observations; they cannot establish how many people used a blockchain application. A heavily traded token can coexist with limited service demand, while useful infrastructure may create value without equivalent token-holder claims.

For the distinct question of service revenue versus subsidies, see the existing DePIN revenue comparison. Locate the article by its title rather than assuming a token’s exchange volume is its network revenue.

Save a review sheet with explicit limits

Record the source query, contract addresses, sample dates, event definitions, treatment of contracts and failures, clustering assumptions and incentive periods. Preserve both raw observations and adjusted counts. Present a range or an unresolved limitation where ownership cannot be established.

A defensible conclusion is specific: the selected contracts recorded a stated number of successful service events under the documented rules. Converting that result into a count of unique people, paying customers or sustainable demand requires additional evidence.