"It is all on the blockchain" is true and unhelpful. The data is public, but it is stored in a form designed for verifying transactions, not for answering questions. How you get at it determines what you can ask, how long it takes and what it costs. There are four broad kinds of source, and serious analysis usually combines them.
1. Nodes
A node is a computer running the blockchain's software with a copy of the ledger. You can run your own or rent access from a node provider. Nodes answer narrow, precise questions: the balance of this address at this block, the details of this transaction, the events this contract emitted between these blocks.
Good for: authoritative answers, recent data, verifying a specific fact.
Bad at: anything that starts with "all". A node has no concept of "every address this wallet has ever paid" or "everything this address has done across every asset". You would have to scan the chain's entire history and build that index yourself. Historical state also requires an archive node, which is large and expensive to run.
2. Indexed data APIs
API providers run the nodes, scan the history and build the indexes, then expose the results as ready-made answers: a wallet's full decoded history, its balances at any past block, its positions inside lending and staking protocols, prices at a given time, labels for known entities. Providers in this category include Alchemy, Covalent (GoldRush), Moralis, QuickNode and Zerion, each with different coverage and strengths.
Good for: questions about one wallet or a handful of them. Most of what a source-of-funds report or a holdings statement needs - age, first funder, holdings at a date, counterparties, decoded transactions - is a handful of calls per wallet. Many chains through one interface.
Bad at: questions that fan out. Reading one wallet is trivial. Following funds through six hops, each of which splits three ways, or searching years of history for every address a family's wallets ever funded, means thousands of calls, which is a matter of plan limits and patience. You are also bounded by the endpoints the provider chose to build.
3. Warehouses and data feeds
The third approach puts the chain's history into an analytical database where it can be queried with SQL. Hosted platforms such as Dune and Allium, and the public blockchain datasets on Google BigQuery, take this route. Some API providers also offer feeds that stream decoded data into a database you own.
Good for: questions across many addresses or many years. "Find every address these twenty wallets ever funded, and where each one sent the money next" is one query. Tracing across many hops, finding undeclared wallets, and matching the two legs of a bridge across chains all belong here.
Bad at: convenience and freshness. You need to know the schema and write the queries. Costs scale with the data scanned, and a careless query over a large chain is expensive. Coverage of newer chains varies.
4. Labels
None of the above tells you that an address is an exchange's hot wallet, a bridge, a lending protocol or a sanctioned entity. That knowledge comes from label sets: some bundled with API providers, some public (block explorers, open-source repositories, published sanctions lists), and some proprietary and expensive, which is the core asset of compliance vendors such as Chainalysis, Elliptic, TRM and Scorechain.
Labels are the least glamorous source and the most consequential. An unlabelled exchange deposit address looks like a dead end when it is in fact the one place a solicitor can send a letter. An unlabelled bridge looks like funds vanishing when they have simply moved to another network. Much of the difference between good and bad on-chain analysis is label quality.
What you cannot get from any of them
- Inside exchanges. Trades and balances within a centralised exchange never touch the chain.
- Order-book venues and other off-chain matching.
- Identity. Addresses are pseudonymous. Links to real people are inferences or come from outside the chain.
- Intent. The ledger records what happened, never why.
Choosing
| Question | Best starting point |
|---|---|
| What has this wallet done? | Indexed API |
| What did this wallet hold at a past date, and what was it worth? | Indexed API, plus a price source |
| Which addresses did these wallets fund that nobody has declared? | Warehouse or data feed |
| Where did the funds from this transaction end up, six hops and a bridge later? | Warehouse or data feed, plus labels |
| Did this specific transaction happen as claimed? | Node or block explorer |
| Is this address sanctioned? | Published sanctions lists |
Two practical rules follow. First, fix the question before choosing the tool: most wasted effort comes from trying to answer a many-hop or many-year question through a single-wallet interface, or the reverse. Second, whatever the source, record exactly what was queried and when. On-chain analysis is only as credible as it is reproducible.