What on-chain data is
A public blockchain such as Bitcoin is, at its core, a shared record of every transaction ever confirmed on the network. Anyone running a node can download that record and read it. On-chain data is simply information taken from that record: how many transactions were confirmed in a day, how much value moved, how old the coins in a transaction were, and how much was paid in fees.
On-chain analysis is the practice of turning those raw records into summaries and ratios, then asking what they might say about how a network is being used. It is different from looking at a price chart. A price chart describes what traders agreed to pay on exchanges. On-chain data describes what happened on the ledger itself, which is often a separate and sometimes only loosely related activity.
This article is educational. It does not suggest that any metric predicts prices, and nothing here is financial advice.
Where the data comes from
Every full node keeps a copy of the chain and checks each block against the rules. The raw material is therefore the same for everyone: blocks, each containing transactions, each transaction listing inputs and outputs.
Bitcoin uses an unspent transaction output model, often shortened to UTXO. Instead of account balances, the ledger tracks individual chunks of coin that have been created and not yet spent. Other networks, such as Ethereum, use accounts with balances, and their data looks different. Most people do not run their own analysis software. They use data providers, block explorers and dashboards that index the chain and publish ready-made charts. Those providers add their own choices about how to count and group things, which matters later.
What can be measured directly
Some quantities come straight from the ledger with little interpretation:
- Transaction counts and sizes. How many transactions a block holds and how much space they use.
- Fees. What senders paid to have transactions included. Congestion shows up here, as covered in the article on mempool congestion.
- Block production. How quickly blocks arrive, which relates to hash rate and the difficulty adjustment.
- Coin age. When an output was created and when it was last spent.
- Supply on the ledger. The total issued so far, which is not the same as the amount that is realistically available to trade, because of lost coins and long-dormant holdings.
These are observations, not conclusions. A count of transactions tells you that transactions occurred, not who made them or why.
What has to be inferred
Many popular metrics are built on guesses layered on top of the raw data. The ledger does not record names. It records addresses, which are strings that control coins. To say that a particular group of addresses belongs to one exchange, one fund or one person, an analytics firm has to apply heuristics, such as assuming that addresses used together as inputs to one transaction share an owner. That can be wrong, and the methods are usually not fully public.
So metrics fall roughly into two families. Direct ones, like fee totals, are fairly solid. Inferred ones, like exchange balances or counts of large holders, depend on labelling quality. The article on the limits of on-chain data looks at those problems in detail.
Common metric families
Beginners meet a handful of recurring ideas.
Activity. Active addresses and transaction counts try to describe usage. Active addresses are tempting but imperfect, because one person can use many addresses and one address can serve many people.
Valuation ratios. Realized cap revalues each coin at the price when it last moved, and the MVRV ratio compares ordinary market capitalization with that figure. These are attempts to describe whether holders are in aggregate sitting on gains or losses.
Holder behaviour. Coin age distributions, known as UTXO age bands, group coins by how long they have been still. Studies of whale wallets look at how concentrated holdings are.
Flows. Exchange flows count coins moving to and from addresses believed to belong to exchanges.
Network security and capacity. Hash rate describes mining effort, and fee and mempool data describe demand for block space.
Each of these has its own article in this section, and each comes with caveats.
What on-chain analysis cannot do
It helps to be clear about the boundaries.
First, it sees only one slice of activity. A large share of trading happens inside exchanges and custodians, where it is recorded in private databases and never touches the chain. When someone buys on an exchange, the coins usually do not move on the blockchain at all. This means order book activity and most derivatives trading are invisible to on-chain data.
Second, it describes the past. A chart of coin movements shows what has happened, and past patterns do not reliably repeat. Any claim that a given metric signals a turning point should be treated cautiously, in the same way you would handle claims in the article on evaluating predictions.
Third, it is easy to find stories after the fact. With dozens of metrics and many time windows, some will line up with a price move by chance. Cherry-picking a chart that fits a narrative is a common error.
Fourth, the networks change. Wallet software, custody practices and fee habits evolve, so a metric that meant one thing several years ago may mean something different now. Moves between wallet types, for example from one custodian’s wallets to another’s, can look like changes in behaviour when nothing economic has changed.
A sensible way to read the data
A careful reader tends to follow a few habits:
- Find out how the metric is defined and who computes it. Methods differ between providers, so two charts with the same name can disagree.
- Separate direct observations from inferred labels.
- Ask what else could explain the same picture. A spike in transfers might reflect a custody reshuffle rather than a change in sentiment.
- Treat any single metric as one input among many, alongside context such as market sentiment and wider conditions.
- Remember that cryptocurrency prices are volatile, that past performance does not predict future results, and that people can lose everything they invest.
Used this way, on-chain analysis is a way to understand how a network works and how people use it. It is a tool for asking better questions, not an oracle that supplies answers.