How to read an on-chain transaction: hashes, logs, transfers, and what they mean

Updated July 2026 · CryptoTaxEdge

A transaction shown as a structured card with labeled fields for from, to, method, and event logs, one highlighted.

A blockchain transaction is a small, fixed record with a handful of named parts. Once you know what each part is for, most transactions become readable, and the tax-relevant details stop hiding.

A transaction is the atomic unit of activity on a chain. Everything a wallet does, sending a token, swapping, supplying to a pool, minting an NFT, is a transaction, and each one is stored the same way: a request the wallet signed, plus a receipt the network produced once it ran. Learning to read that structure is the single most useful skill for anyone reconciling crypto for tax, because it lets you check what a wallet actually did instead of trusting a label someone else assigned.

The parts of a transaction

Every transaction on an account-based chain carries the same core fields. Here is what each one is and whether it matters for tax work.

Transaction hash: A unique identifier for the transaction, a long string beginning with 0x. It is the permanent name of this exact transaction and the key used to match a chain record to a ledger row. When a tax tool asks for a transaction, this is what it wants.
From: The address that signed and sent the transaction. For a wallet you are reconciling, this tells you the transaction was initiated by the taxpayer rather than received passively.
To: The address the transaction was sent to. This is often a smart contract, not a person. A to field pointing at a known protocol contract is the first clue that the transaction is more than a simple send.
Value: The amount of the chain's native asset (ETH on Ethereum, for example) moved directly by the transaction. Many token transfers show a value of zero here, because the tokens move inside the logs rather than as native value. A zero value does not mean nothing happened.
Input data: The encoded function call: which method was invoked and with what arguments. Decoded, it reveals intent, whether the wallet called swap, deposit, withdraw, or approve.
Logs (events): The record of what the contracts emitted while the transaction ran. This is where token transfers live, and it is usually the most tax-relevant section.
Gas and fee: The cost paid to the network to run the transaction, denominated in the native asset. It is a real cost and can matter for basis and expense tracking.
Status: Success or failure. A failed transaction still costs gas but moves no assets. Recording a failed transaction as a trade is a common and avoidable mistake.

The logs are where the money moves

For token activity, the logs matter more than the top-level fields. Each time a token moves, the token's contract emits a transfer event recording the sender, the receiver, and the amount. A single transaction can emit many such events. Reading the logs from the wallet's point of view, listing what left and what arrived, reconstructs the real economic effect of the transaction even when the top-level value is zero.

One detail trips up manual reads constantly. Token amounts in the logs are stored as raw integers scaled by the token's decimals. A balance shown as 1000000 for a six-decimal token like USDC is one dollar, not a million. Getting decimals wrong turns a small transfer into a fortune or a fortune into dust, so any careful read applies the token's decimal places before believing a number.

Reading a transaction end to end

Put the parts together on a real shape, a token swap on a decentralized exchange.

To points at a router contract, so this is a contract interaction, not a plain send.
Input data decodes to a swap function, confirming intent.
Logs show two transfer events from the wallet's perspective: one token out, a different token in.
Value may be zero if neither side was the native asset.
Status is success, and gas records the fee paid.

Read together, those fields say one clear thing: the wallet exchanged one token for another, for a known fee, in a transaction that succeeded. That is a disposal of the token that left and an acquisition of the token that arrived, and it is legible directly from the transaction without trusting any external tag.

What reading gets wrong when done by eye

Manual reading works for a handful of transactions and breaks down at volume. The failure points are consistent: decimals applied incorrectly, internal transfers missed because they sit deep in the logs, failed transactions counted as trades, approvals mistaken for movements, and multi-step transactions collapsed into a single misleading line. None of these are exotic. They are the ordinary friction of doing by hand what is really a parsing job.

This is the read CryptoTaxEdge automates. Enter a transaction hash and the engine decodes the input data, walks the logs with correct decimals, filters the events with no economic substance, and returns a single classified result with the reasoning attached. When the signals disagree or the evidence is thin, it flags the transaction for a person instead of guessing. The goal is the same read a careful analyst would do, done consistently across thousands of transactions.

Once the anatomy is familiar, a transaction stops being an opaque string and becomes a short, checkable record. That is the foundation everything else in crypto tax rests on: you cannot reconcile a ledger, or understand a DeFi position, without first being able to read the transactions underneath. The full set of labels the engine assigns, and the evidence behind each, is laid out in the classification taxonomy.

Grade a report free See the classification taxonomy

Not tax advice. CryptoTaxEdge is software, not a licensed tax advisor. This guide is general and informational only. Verify results and consult a qualified tax professional before filing.