At the core of bitcoin is an open ledger, so with the proper skill any transfer can be traced from address to address. A whole industry has grown out of this: traders track whales and inflows to exchanges, blockchain forensics experts help recover stolen funds, and compliance filters out "dirty" coins.

In this guide we will go step by step through how to analyze transactions manually, how to put the work on a conveyor with the help of tools and automation, and also why even the most advanced tracing gives a probability rather than a one-hundred-percent answer.

We will leave basic definitions and market metrics out of scope — there is a separate material for them in a card format.

Part 1. Analyzing transactions manually

Step 1. Finding a transaction by TXID

Every transfer on the blockchain has a unique identifier — the TXID, the transaction hash. This is a long string, usually of 64 characters, which the network obtains by running all the transfer data — inputs, outputs, amounts, and signatures — through the SHA-256 algorithm.

It is practically impossible to forge such a hash: the slightest edit of the data gives a completely different string, so two identical TXIDs do not exist. In essence it is a "receipt number" by which any node on the network can find and verify the operation.

The way to obtain the hash depends on what you already have:

• if the transfer has already been made — it can be opened in the history of a wallet or exchange. Next to the operation there is usually a link such as "View in explorer": it leads to the transaction page, where the identifier is shown in full;
• if you only have the sender's or recipient's address — it is pasted into the search bar of any blockchain explorer. The address history will open with all transfers; the needed transaction can be identified by amount and date, and its hash found on the transaction's own page.

Step 2. Understanding the structure of a transaction: inputs, outputs, and change

Unlike a bank account, bitcoin does not store the balance as a single number. The network works on the UTXO (unspent transaction output) model: funds exist as separate "banknotes" of different denominations, while the wallet stores only the keys to them. The available balance is the sum of all such outputs controlled by the owner.

A "banknote" cannot be spent partially. During a payment such an output goes into the transaction in full, and in return the network creates two new ones: one to the recipient, the second as change back to the sender at a fresh address.

Let us take an example. Alice has an output of 5 BTC, and she transfers 0.01 BTC to Bob. On the blockchain there appear an input of 5 BTC, a payment of 0.01 BTC, and change of ~4.99 BTC (minus the fee).

Any observer can see the whole operation through an explorer — a "round" payment is easy to distinguish from "fractional" change. The determination of the change address in blockchain forensics is built on this feature.

Step 3. Checking confirmations and the mempool

A sent transaction does not reach the blockchain instantly. First the transfer ends up in the mempool — a common queue of operations awaiting inclusion in a block. At this stage delays are possible: miners usually prioritize operations with a higher fee, so with too low a fee a transfer may remain in the queue for a long time.

As soon as the operation reaches a block, it gets its first confirmation. After the record is included in a block, it receives its first confirmation. With each subsequent one the level of reliability grows, and the probability of cancellation becomes ever lower. For small amounts one or two confirmations are usually enough, whereas for large payments it is customary to wait for six.

This is convenient to follow in real time by the hash: the explorer will show whether the transfer is hanging in the queue, which block it ended up in, how many confirmations it has gained, and what fee the sender paid. If the operation is stuck for a long time, the same page will suggest the reason — most often an underpriced fee.

Step 4. Tracing the path of a coin

Each input of a new operation refers to a specific output of one of the previous ones — by its hash, and it can have several inputs and outputs at once. Therefore transfers form not a single chain but a branched network: coins in it converge and diverge between addresses.

Along this network the movement of funds can be traced in both directions — forward to new addresses and back, all the way to the coinbase transaction in which they first appeared as a reward for a mined block.

In practice an analyst follows the output addresses and looks at where the funds went next. Then they repeat the same with the new addresses — step by step, until a full chain comes together.

This is how characteristic routes emerge on the blockchain: a transfer to an exchange, the splitting of a large sum into parts, or the withdrawal of stolen funds through several intermediate wallets.

Example: in 2025 an early investor's address showed activity for the first time after 13 years of dormancy, transferring 909 BTC (about $85 million) to a new wallet. These coins were received back in 2012–2013, when the price of bitcoin did not exceed a few dollars.

Such a transfer is visible in any explorer: it is enough to open the address, follow the output chains, and see where the funds moved next.

Part 2. Putting analysis on a conveyor

Manual analysis is good when there are one or two transactions. But the ledger is replenished every second, and thousands of transfers cannot be covered by eye.

Here automation comes to the rescue: programs themselves request data from the network, calculate metrics, and send a notification at the right moment. Let us look at its three levels — access to data, analytics, and monitoring.

Step 5. Connecting to data via API

The first level is programmatic access to the blockchain via the APIs of nodes and explorers. This is an interface through which a script requests the same information we could previously see on the transfer page (but without human involvement and in any volume).

The mempool.space service has two options to choose from. The REST API responds to one-off requests: transaction status, address balance, mempool state. The WebSocket API keeps a constant connection and sends updates itself — you can subscribe to an address and receive a signal every time a new transfer passes through it.

For bulk checks Blockchair and Bitquery are suitable: they return data for many addresses at once and support webhooks.

Step 6. Automating analytics

The second level is platforms that let you write a query once and receive a ready dashboard instead of a one-off result.

On Dune blockchain data is queried in the SQL language and displayed on charts; a report on exchange flows, whale activity, or top holders updates itself, without a repeat query.

Flipside is arranged similarly — it also has a free Python SDK through which data can be pulled straight into custom scripts.

The key difference from the manual method is simple: the query is written once but works constantly. Previously an analyst reviewed the chart daily — now there are dashboards that update themselves.

Step 7. Setting up monitoring and alerts

The third level is notifications instead of manually refreshing the page. A combination of "API plus bot" watches the needed addresses and sends a notification as soon as funds arrive or leave. This is how both public alerts about large whale trades and private alerts work, for example about the withdrawal of coins from a specific wallet.

A basic set can be configured even without programming: platforms like Arkham offer ready-made alerts about transfers and whale activity that come by email or to the app. For those who need their own event-handling logic, webhooks are suitable — they automatically send a notification to the server when a specified event occurs.

Part 3. Tracing and its limits

Step 8. How blockchain forensics works

The pinnacle of automation is the tracing of stolen coins and the investigation of transactions. Forensic engines repeat the logic of manual analysis but apply it on the scale of the entire network.

At the heart of this technology lies the clustering of addresses by heuristics, that is, assumption rules; two of them are especially important:

• common input: if several UTXOs are spent in one transaction, they are with high probability controlled by a single owner;
• change address determination: by the feature from Step 2 — a round payment versus fractional change — the engine works out which of the outputs returned to the sender.

On top of clustering, the recognition of typical laundering schemes is added. This is, for example, the splitting of sums or "peeling" — when small portions are pinched off a large wallet again and again.

Next comes risk assessment and attribution: tying clusters to real exchanges, services, or individuals. Both commercial platforms (Chainalysis, TRM, Elliptic) and open engines (GraphSense, BlockSci) do this.

Step 9. Can automation be trusted

Automatic analysis has a fundamental limitation. Clustering gives a probability, not a fact. Heuristics make mistakes: for example, the CoinJoin technology deliberately combines the UTXOs of different users in one transaction, which causes the common-input rule to misfire.

The risk of data leakage can also be reduced manually. The Coin control function in wallets (for example, Sparrow or Trezor Suite) lets you choose yourself which UTXO to spend: pick an output to match the payment amount and not mix coins from different sources in one transaction. This reduces change and prevents the common-input heuristic from triggering — the very clues on which clustering is built.

Bitcoin provides not anonymity but pseudonymity — a weaker property that persistent analysis often "breaks through," but not always: the result remains an estimate, albeit a well-founded one. As Chainalysis emphasizes, attribution heuristics give a probabilistic result rather than certainty, so a risk assessment is only a basis for the analyst's decision, not a verdict.

Hence a practical conclusion. It is worth distinguishing automatic grouping of addresses from human-verified attribution: the first is a hypothesis, the second is a conclusion. The result of a risk assessment is a reason to take a closer look at an address, not a sentence on its owner.

***

The open ledger makes every bitcoin transfer traceable — all on-chain analysis is built on this. For manual work the basics are enough: to know what a TXID is, to understand the UTXO model and the mechanics of change, to read inputs, outputs, and confirmations in an explorer. This is enough to go through chains of transactions and see where the funds moved.

Automation in the form of APIs, SQL dashboards, and bots does not remove the need for these basics — it simply scales the work: what an analyst does by hand with one transaction, the tools repeat for the entire network.

At the top stands forensics with clustering and risk assessment. However, it relies on probabilistic heuristics, and therefore gives hypotheses rather than proof.

It is logical to master the topic from the bottom up: first the explorer, then APIs and dashboards, and only then specialized on-chain analytics tools. At the same time, the deeper the tracing, the more important it is to distinguish the probable from the proven.

Source: ForkLog