Crypto news

18.06.2026
11:42

How to read a Bitcoin transaction: a complete guide to on-chain analysis

img-1560f4bc4a53c1a5-324581824690277

The public Bitcoin ledger is not just a database, but a powerful tool for analysis. Every transaction leaves an indelible trace, and with the right skills, any transfer can be traced from sender to recipient. A whole industry is built on this: traders track whale movements, blockchain forensics experts recover stolen funds, and compliance departments filter out "dirty" coins. In this article, I will break down how to analyze transactions independently, automate the process, and where the limits of even the most advanced tracing lie.

Part 1. Manual Transaction Analysis

Step 1. Finding a Transaction by TXID

Every transfer on the blockchain has a unique identifier — TXID, or transaction hash. This is a 64-character string generated by the SHA-256 algorithm based on all the transfer data: inputs, outputs, amounts, and signatures. Forging such a hash is practically impossible — the slightest change in data produces a completely different result. Essentially, it's a "receipt number" that any network node can use to find and verify the operation.

How to get a TXID? If the transfer has already been made, open your wallet or exchange history — next to the operation, there is usually a link saying "View in explorer." If you only have the sender's or recipient's address, paste it into the search bar of any blockchain explorer. The address history will open, where you can identify the desired transaction by its amount and date, and find its hash on the operation's page itself.

Step 2. Understanding Transaction Structure: Inputs, Outputs, and Change

Unlike a bank account, Bitcoin does not store a balance as a single number. The network operates on the UTXO (Unspent Transaction Output) model: funds exist as separate "banknotes" of various denominations. You cannot partially spend a "banknote" — when making a payment, it is spent entirely, and in return, the network creates two new outputs: one for the recipient and the second as change back to the sender at a fresh address.

Example: Alice has an output of 5 BTC, and she sends Bob 0.01 BTC. The blockchain shows an input of 5 BTC, a payment of 0.01 BTC, and change of ~4.99 BTC (minus the fee). Any observer can see this operation through an explorer — a "round" payment is easily distinguishable from "fractional" change. This very characteristic is used to identify the change address in blockchain forensics.

Step 3. Checking Confirmations and the Mempool

A sent transaction does not appear on the blockchain instantly. First, it enters the mempool — a general queue of operations waiting to be included in a block. Miners prioritize operations with higher fees, so a transfer with too low a fee can get stuck for a long time. Once an operation is included in a block, it receives its first confirmation. With each subsequent block, the level of reliability increases, and the probability of reversal decreases. For small amounts, one or two confirmations are usually sufficient; for large ones, six are needed.

Using the hash, it's convenient to monitor this in real-time: the explorer will show whether the transfer is pending in the queue, which block it entered, how many confirmations it has received, and what fee the sender paid.

Step 4. Tracing the Coin's Path

Each input of a new operation references a specific output from one of the previous ones — by its hash. Therefore, transfers do not form a single chain but a branched network. The movement of funds can be traced in both directions: forward to new addresses and backward, all the way to the coinbase transaction where the coins first appeared as a reward for a mined block. In practice, an analyst follows the output addresses and sees where the funds went next, step by step, until a complete chain is formed. This reveals characteristic routes on the blockchain: a transfer to an exchange, the splitting of a large sum, or the withdrawal of stolen funds through several intermediate wallets.

Part 2. Automating Analysis

Manual analysis is good for one or two transactions, but the ledger is updated every second. This is where automation comes in: programs themselves request data from the network, calculate metrics, and send notifications. Let's break down three levels of automation.

Step 5. Connecting to Data via API

The first level is programmatic access to the blockchain via APIs of nodes and explorers. For example, the mempool.space service has a REST API for one-time requests and a WebSocket API for a persistent connection that sends updates automatically. 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 allow you to write a query once and receive a ready-made dashboard. On Dune, blockchain data is queried using SQL and displayed on charts; a report on exchange flows or whale activity updates itself. Flipside works similarly with a free Python-SDK. The key difference from the manual method: the query is written once and runs continuously.

Step 7. Setting Up Monitoring and Alerts

The third level is notifications instead of manually refreshing a page. An "API plus bot" combination monitors the desired addresses and sends a signal as soon as funds arrive or leave. Platforms like Arkham offer ready-made alerts for transfers and whale activity. Webhooks are suitable for custom processing logic.

Part 3. Tracing and Its Limits

Step 8. How Blockchain Forensics Works

The pinnacle of automation is tracing stolen coins. Forensics engines replicate the logic of manual analysis but on the scale of the entire network. The foundation is address clustering based on heuristics. Two key ones are: "common input" (if several UTXOs are spent in one transaction, they are highly likely controlled by a single owner) and "change address identification." On top of clustering, recognition of typical money laundering schemes is added, such as splitting sums or "peeling." Next comes risk assessment and attribution — linking clusters to real exchanges, services, or individuals.

Step 9. Can Automation Be Trusted?

Automated analysis has a fundamental limitation. Clustering provides a probability, not a fact. Heuristics can be wrong: for example, CoinJoin technology deliberately combines UTXOs from different users in one transaction, causing the common input rule to misfire. Bitcoin provides not anonymity, but pseudonymity — a weaker property that persistent analysis often "cracks," but not always. The result remains an estimate, albeit a well-founded one. As emphasized by Chainalysis, attribution heuristics yield a probabilistic result, not certainty. Therefore, it is worth distinguishing between automatic address grouping and human-verified attribution: the former is a hypothesis, the latter is a conclusion.

The public ledger makes every Bitcoin transfer traceable. For manual work, a basic understanding is enough: knowing the TXID, understanding the UTXO model and change mechanics, and reading inputs, outputs, and confirmations in an explorer. Automation scales this work, while forensics with clustering provides hypotheses, not proof. My advice: master the topic from the bottom up — first the explorer, then APIs and dashboards, and only then specialized tools. The deeper the tracing, the more important it is to distinguish the probable from the proven.