How Blockchain Investigators Follow the Flow of Funds

Following the flow of funds is the core discipline of blockchain investigation. It is not a search, and it is not a lookup. It is the disciplined reconstruction of where value moved, in what order, through which intermediaries — and, just as importantly, a record of where that reconstruction stops being supportable.

This guide describes how that work is actually done, and where it fails.

What "flow of funds" actually means

A public blockchain records transfers of value between addresses. Following the flow of funds means reconstructing a path through those transfers: starting from a known point, identifying what left it, where it went, and repeating that until you reach either a terminus or the limit of what the data supports.

The word flow is doing real work. A single transaction is a fact. A flow is an interpretation built from many facts, and interpretations can be wrong even when every underlying fact is correct. The discipline lies in keeping those two layers separate — knowing at all times which parts of your picture are recorded on-chain and which parts are your reading of them.

Where an investigation starts

Almost every investigation begins from one of two places.

A transaction. You have a hash. It is a fixed point: a specific movement, at a specific block, with specific inputs and outputs. From here you work outward — backward toward origin, forward toward destination.

A wallet. You have an address. This is a broader starting point and a weaker one. An address has a history rather than a single event, and that history may span years, mix unrelated activity, and belong to software rather than a person.

Neither starting point tells you who is involved. Both tell you what happened.

Reading direction

Every transfer has a direction, and direction is the first thing to establish. Inbound value tells you what an address received and from whom. Outbound value tells you what it sent and to where.

Direction sounds trivial until an investigation grows. Once you are looking at hundreds of transfers across dozens of addresses, the most common error is not a misread hash — it is losing track of which way value was moving, and constructing a path that runs against the flow it claims to describe.

Two further properties matter as much as direction:

• Amount, which determines whether a branch is material or noise.
• Time, because a blockchain is an ordered ledger, and order constrains what can have caused what. Value cannot arrive at an address before it left the one that sent it.

Building a timeline early — even a rough one — prevents most structural errors later.

Counterparties

The address on the other side of a transfer is a counterparty. Some counterparties are meaningful; most are not.

A counterparty may be another self-custodied wallet, a deposit address at an exchange, a smart contract, a bridge, a mixing service, or an address that has never been seen before and will never be seen again. Establishing which kind you are looking at usually matters more than the amount involved, because it determines what the next step of the investigation even is.

Two data models, two ways of tracing

Chains differ in how they represent ownership, and the difference changes the mechanics of tracing.

UTXO-based chains — Bitcoin and its derivatives — do not hold balances. They hold unspent transaction outputs. A transaction consumes existing outputs as inputs and creates new ones. There is often no single sender and no single recipient: one transaction may consume ten inputs and create three outputs, one of which is change returning to the originator.

This has a direct consequence. On a UTXO chain, "the amount sent" is frequently ambiguous, because part of the output is change. Treating a change output as a payment to a third party is one of the most common tracing errors, and it inflates apparent flows substantially.

Account-based chains — Ethereum and most EVM networks, and Solana — maintain balances against accounts. A transfer debits one account and credits another. Direction is explicit, and there is no change output to misread.

The trade-off is that account-based chains carry far more activity that is not a simple transfer.

What is actually moving

Three categories of movement look similar in a block explorer and mean quite different things.

Native asset transfers move the chain's own currency — BTC, ETH, SOL. These are the most straightforward to follow.

Token transfers move assets defined by a smart contract. The token contract maintains its own ledger; the transfer is an event emitted by that contract rather than a movement of the chain's native asset. Two practical consequences follow. Token symbols are not unique and can be chosen freely, so a symbol alone never identifies an asset — only the contract address does. And a token with no liquid market may show a large nominal quantity while representing no meaningful value at all.

Smart-contract interactions are where naive tracing breaks down. A transaction to a contract may swap assets, deposit into a protocol, route through several venues, or emit dozens of internal transfers that never appear as top-level activity. Value can enter a contract as one asset and leave as another, at a different address, in a different transaction. Following the flow through a contract means reading what the contract did, not just that it was called.

Multi-hop tracing

Real movement rarely happens in one step. Value moves from A to B to C, sometimes splitting at each hop, sometimes recombining later.

Two shapes recur often enough to be worth naming. Fan-out is one address distributing to many — which may indicate dispersal, or may simply be a payroll batch or an exchange processing withdrawals. Consolidation is many addresses feeding into one, which may indicate collection, or an exchange sweeping deposits.

Neither shape is evidence of intent. Both are extremely common in ordinary operations. What makes a pattern notable is context — timing, amounts, the nature of the counterparties — not the shape alone.

Multi-hop tracing also degrades. Each hop introduces the possibility that you have followed the wrong branch, and confidence should decline with distance from the starting point. An investigator who is as certain at hop twelve as at hop one has stopped doing analysis.

Exchanges: where the trail changes character

When funds reach an exchange deposit address, on-chain tracing does not continue — it stops.

This is a structural boundary, not a technical limitation to be worked around. An exchange takes custody. Internal movements between customer accounts are recorded in the exchange's own systems, not on the chain. Funds that later leave the exchange come from pooled hot wallets and cannot be connected to a specific earlier deposit by on-chain data alone.

The correct conclusion at that point is precise: funds reached an address associated with this exchange at this time. Anything beyond that — who controlled the account, what happened next — requires records only the exchange holds.

Bridges and cross-chain continuation

Bridges move value between chains, and they break a naive trace for a different reason: the trail does not end, it continues somewhere your current view does not cover.

Following value across a bridge means identifying the deposit on the source chain, understanding the bridge's mechanism, and locating the corresponding release on the destination chain. Matching the two sides relies on correlation — amount, timing, and the bridge's own accounting. That correlation is usually strong, but it is still an inference, and it should be recorded as one.

Clustering is inference, not identity

Clustering groups addresses believed to share control. The most established technique is common-input ownership on UTXO chains: when several inputs are spent in one transaction, the spender plausibly controlled all of them, because signing requires the corresponding keys.

Clustering is genuinely useful. It is also a heuristic, and it fails in specific, well-understood ways — collaborative transactions such as CoinJoin deliberately break the assumption, custodial services routinely spend on behalf of many users, and shared-custody arrangements separate control from ownership.

A cluster is a hypothesis about control. It is never, on its own, a statement about identity.

The distinction is not pedantic. Treating a cluster as an identity is how one wrong assumption silently contaminates every conclusion built on top of it.

Attribution and its limits

Attribution assigns a real-world label to an on-chain address. It is the most consequential step in an investigation and the least supported by the chain itself, because blockchains contain no identity information whatsoever.

Every attribution comes from outside the chain: public disclosures, an entity publishing its own address, court filings, service documentation, or a labelled dataset. Each carries its own reliability, and each can be wrong or out of date. Addresses change hands. Labels are copied between datasets until a single early error looks like consensus.

Attribution should therefore always travel with its source and its confidence. An address labelled from an exchange's own published documentation is not in the same evidentiary category as one labelled because several websites repeat the claim.

Recording evidence

An investigation that cannot be reconstructed by someone else is not finished. At minimum, record for each step:

• The transaction hash and block, which are immutable references.
• The addresses on both sides, in full.
• Amount and asset, including the token contract address where relevant.
• The timestamp, and the chain it came from.
• The reason you followed this branch rather than another.
• Any attribution used, with its source.

That last item is the one most often skipped and the most valuable. Months later, the question is rarely what did you find — it is why did you follow this path.

Confidence and uncertainty

Findings should be graded, and the grading should be visible.

Keeping these tiers separate is what allows an investigation to be revised without being discarded. Collapsing them — presenting an assessment in the language of a confirmed fact — is the failure that most often turns a defensible analysis into an indefensible accusation.

Common mistakes

• Reading change outputs as payments, inflating apparent flows on UTXO chains.
• Trusting token symbols, which are freely chosen and routinely spoofed.
• Treating a cluster as a person, converting a heuristic into an identity claim.
• Following value past an exchange deposit, which the data does not support.
• Ignoring contract internals, and missing where value actually went.
• Losing the timeline, and asserting a sequence the block order contradicts.
• Carrying confidence forward unchanged across many hops.
• Recording conclusions without their basis, leaving work that cannot be checked.

What on-chain data can and cannot prove

It can establish that a transaction occurred; which addresses were involved; the amount and asset; the order of events; the state of an address at a point in time; and that a specific key authorised a specific transfer. These are matters of record.

It cannot establish who controls an address; whether a transfer was voluntary; the purpose of a payment; the relationship between two parties; whether custody was shared or delegated; or what happened to funds once they entered a custodial service. None of this is recorded, and no amount of analysis extracts it from data that never contained it.

The gap between these two lists is where investigations go wrong. Most flawed conclusions are not the result of misreading the chain — they come from asserting something the chain was never able to say.

A practical workflow

1. Fix the starting point. A transaction hash or an address, recorded exactly.
2. Establish the timeline. Order events before interpreting them.
3. Classify counterparties. Wallet, contract, exchange, or bridge — this determines the next step.
4. Follow material value. Set a threshold, and record it rather than applying it implicitly.
5. Read contract interactions properly where they appear.
6. Mark boundaries explicitly at exchanges and bridges.
7. Cluster cautiously, and label every cluster as inference.
8. Attribute with sources, never from memory or repetition.
9. Grade every finding as confirmed, assessed, or unconfirmed.
10. Write it so someone else can repeat it — including the branches you chose not to follow.

The strength of a blockchain investigation comes from the discipline of the method, not from the volume of data examined. The chain records a great deal with certainty. Knowing precisely where that certainty ends is what separates analysis from speculation.