On-chain for beginners

What this lesson explains and who it is for

This lesson shows how to read public network data so the conclusion you draw stays inside what that data actually measures. It is for the reader who opens a block explorer and sees numbers without context: “active addresses”, “exchange inflows”, “TVL”. For every metric we give the formula, the question it answers and what it cannot say. No price forecasts or “signal” readings here — instead, a way to write the rule down before looking at the chart, so the measurement is verifiable rather than fitted to a thesis.

On-chain data is a layer of verification and context. It does not replace risk management or entry and exit rules — without those, no metric will repair that.

What on-chain data is and what it is not

On a public network you can check a transaction hash, the fee paid to execute it, the contract address of a token, the number of holders and the transfer history. This is the accounting layer of the network — a record of what has been confirmed.

What this data is not:

• it is not identification of people. An address is not an identity, and one user may hold many;
• it is not intent. A transfer shows a flow, not a reason;
• it is not a forecast. A metric describes the past and changes with its definition;
• it is not complete. Some activity moves to layer-2 networks and off-chain systems, including tokens that mirror other assets — see stablecoin. The same phenomenon changes how metrics read. If such a token is a stablecoin, its value is decided by the backing of the issuance and the redemption terms, not by the on-chain record — how to check those is in the lesson Stablecoins and de-peg risk.

One practical consequence follows. Public data plus a wrong interpretation is still a loss. A funding rate on a perpetual contract and a sudden withdrawal of liquidity on the spot market are different risk vectors — the explorer helps with the second, it does not remove the first.

Metrics: formula, question and limit

This table is the backbone of the lesson. Read it row by row, not column by column.

The last three columns do different jobs. The formula says what was counted exactly. The question points to the use. The limits column guards against the most common mistake: using a metric to answer a question it does not answer.

Active addresses: a count of addresses is not a count of people

The active addresses metric answers a question about network usage, not about the number of participants. One user may run many addresses, and one exchange serves many users through a few omnibus addresses. The formula counts addresses, not people.

What follows in practice:

1. Fix the measurement window. A day, a week and a month are three different metrics under one name. Changing the window can flip the conclusion.
2. Define what “active” means. Sending, receiving, or both. Without that decision you do not know what you are comparing.
3. Compare the same period year over year, not neighbouring days. Daily swings often come from the calendar, not from user behaviour.
4. Write down what the metric does not cover. Activity outside the main chain and on layer-2 networks changes the picture.

Drawing a conclusion about an “inflow of new investors” from one number crosses the limit of this metric. New addresses do not have to mean new people.

Network fees: what space in a block costs

A network fee is the product of gas units consumed and the price per unit. Total fees in a window therefore answer how much users paid in aggregate to execute transactions. It measures cost and demand for throughput, not market direction.

Three questions this metric answers well:

• whether the cost of a transaction is rising or falling in the chosen window,
• how pressure on network throughput is changing,
• what one type of operation costs compared with others.

And three it does not answer:

• whether the price will rise or fall — fees run high both in panic and in enthusiasm,
• who pays — the fee falls on the sender of the transaction, not the receiver,
• whether a high cost means a lasting trend — the network reacts to temporary congestion.

A separate note on comparisons between networks. A fee on one network and a fee on another are numbers in different units, split among a different set of users. Setting them side by side without converting to a common currency and window compares two different things.

Exchange inflows and outflows: supply versus intent

Net exchange inflow is the difference between the value of transfers into addresses labelled as exchange addresses and the value of transfers leaving them. The metric describes the movement of supply between self-custody wallets and platforms. It answers which way the token is moving, and nothing more.

The most common interpretation error is treating an inflow as an announcement of a sale. The same transfer may mean preparation to sell, a move between your own accounts, collateral for a position, a platform change, or a routine internal exchange operation. The metric contains no reason.

The second problem is technical: the whole metric rests on address labels. If they are incomplete or out of date, the number describes a set you do not know. That is why you read net inflow together with exchange reserves — only together do the two numbers show whether a change comes from a transfer or a shift inside the system. Before using this in a decision, check whether you know how your tool labels addresses, and whether that method is publicly documented.

Market context is filled in by the lesson spot versus perpetual and the comparison of both markets, while the limits of a single position are set by the 1–2 per cent rule.

You write the rule before you look at the chart

A metric without a rule becomes a tool for confirming what you already think. Hence the reversed order: first the record, then the reading.

1. Metric and formula. Name exactly what you measure, and record the definition, not an abbreviation.
2. Measurement window. State the length and the unit. base_value = metric_value_at_the_start_of_the_window.
3. Significance threshold. Write down in advance what change counts as your signal. relative_change = (current_value − base_value) / base_value. A negative result means a decline, a positive one a rise.
4. Invalidation condition. Write what must happen for the hypothesis to stop applying. Without that sentence, every reading can be explained after the fact.
5. Date and source. Note the day of the reading and the tool. The same metric from two sources often differs, because sources use different formulas.

The fourth point matters most and is skipped most often. An invalidation condition turns an observation into a test, and only a test can end with a negative result.

Your measurement log — fill it in with your own data

Keep it in the same file as your trade journal — see journal and review. A measurement log makes sense only if it can be compared with the outcome.

The “conclusion after the fact” column is why this log exists. Fill it in only once the window has passed, not on the day of the reading.

Contract verification before a token swap

Before you swap on a new protocol, run a fixed checklist. A link from social media is not a source.

1. Find the official contract address in the project documentation or on its verified page.
2. Compare it character by character with the address shown in the interface.
3. Check the symbol and the number of decimals in the explorer — fake tokens copy the name but differ in technical details.
4. Check the scope of the permission you are signing, and set the limit yourself.
5. Run a test swap with about fifty dollars (an illustrative figure), an amount whose loss changes nothing, and revoke any unnecessary permission.

Skipping any step with an unknown token is one of the most common ways to lose funds in the self-custody model — not through a market error but a verification error. The sequence of checks is covered more broadly in the lesson security and scams.

When a metric says “do not trade”

1. You cannot state the formula of the metric your decision rests on. A name without a definition is not information but an impression.
2. You have not written the invalidation condition down. If every future reading can be fitted to the thesis, it is not a hypothesis.
3. You do not know how the tool labels addresses. With exchange metrics the whole number depends on labels you cannot see.
4. You base a position on a single event, for example one transfer by a large holder (an illustrative figure), with no exit plan and no risk limit expressed in R units. The structure of the position is then undefined, and the metric supplies nothing but a narrative.

Common mistakes

• Treating a single metric as a complete signal. Read active addresses, fees and flows together, because each looks at a different layer.
• Approvals without a limit on contracts you will not use again. Review and revoke unnecessary allowances, because they keep working without your attention.
• Confusing an audit with a guarantee. An audit limits known classes of bugs; it does not remove economic risk.
• A decision based on a single alert about a large transfer. Without a position plan and a risk limit that is entertainment, not a process.
• Changing the measurement window after the reading. Shortening or lengthening the period as needed is fitting the result to the thesis.
• Comparing values from two different tools. Different sources use different formulas, so the difference may be an artefact of methodology.

A measurable exercise

Pick one publicly documented token and carry out a full measurement.

1. Write down its official contract address from the project documentation and compare it with the interface.
2. Open the explorer and read three facts: the symbol and the number of decimals, the fee of one chosen transaction, and the approximate concentration of balances.
3. For each reading, record the formula, the measurement window and one sentence about what that number does not say.
4. Fill in one row of the measurement log together with the invalidation condition.
5. Note the date of the reading and return to the row once the window has passed, to complete the conclusion column.

The result is one row of the log with a date and one sentence about the limit of interpretation — not an opinion about market direction.

Common questions

Do large transfers to an exchange mean the price will fall?

No. Net inflow describes the direction of the flow, not the intent. The same transfer may be preparation to sell, a move between your own accounts, collateral for a position, or an internal platform operation. The whole metric also rests on address labels you cannot see.

Why write an invalidation condition down before reading a metric?

Because without a condition set in advance, every result can be explained after the fact, and that is exactly what turns a measurement into confirmation of your own thesis. Only an invalidation condition lets an observation end with a negative result and still teach you something. It is also the only way, months later, to tell a sound hypothesis from a lucky guess.

Why verify the contract address when swapping a token?

Because phishing and fake tokens copy the name and the symbol. The official address from the project documentation, compared with the interface and checked for decimals in the explorer, is the minimum in the self-custody model.

Will on-chain data replace technical analysis?

No. It is a different layer of information, answering different questions. Entry and exit rules and your risk limit are still on your side, and public data does not remove uncertainty — it describes the past, not the future.