Most people who own crypto have never actually looked at the raw data behind one of their transactions. Which is understandable — the information is unfamiliar, the format is dense, and there's no obvious starting point. But a blockchain transaction record isn't hiding anything. Once you know what each field represents, the data reads clearly.
This post walks through the anatomy of a real transaction: what the fields mean, where to find the information you actually care about, and how the two dominant models — Bitcoin's UTXO and Ethereum's account model — display that information differently.
Every Transaction Starts with a Hash
The first thing you'll see on any block explorer is the transaction hash — sometimes called a TXID. It's a unique 64-character hexadecimal string, something like:
0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060
This is a cryptographic fingerprint of the transaction data. If anything in the transaction changed — even one character — the hash would be completely different. It's how you look up a specific transaction on a block explorer like Etherscan (Ethereum) or Mempool.space (Bitcoin).
Paste the hash into the search bar and the explorer pulls the full record.
The Core Fields (Ethereum as Baseline)
The account model that Ethereum uses is slightly more intuitive than Bitcoin's UTXO model, so it's a cleaner starting point. Here's what each field actually means.
Status
The first thing to check. A transaction is Pending, Success, or Failed. Pending means it's in the mempool, waiting for inclusion. Success means confirmed. Failed means it went on-chain but something went wrong — typically an EVM execution error, like a smart contract reverting.
One important detail: failed transactions on Ethereum still consume gas. The block space was used; the network doesn't refund you for a failed execution. You paid for the computation, regardless of whether the outcome was what you wanted.
Block
The block number where the transaction was included. This anchors it to a specific point in the chain's history.
Below the block number, you'll see confirmations — how many blocks have been added on top of the one containing this transaction. More confirmations means more finality. For most Ethereum transfers, 12 confirmations is considered probabilistically final. Bitcoin typically uses 6.
Timestamp
When the block was mined. This is the canonical record of when the transaction happened — not when you submitted it, not when your wallet first showed it. The timestamp reflects inclusion in a block, full stop.
From / To
The sender address and the recipient address. For a simple ETH transfer, From is the sender, To is the recipient. For a smart contract interaction, To is the contract address — not a person.
This is where reading gets more nuanced. Sending ETH to a contract address (interacting with Uniswap, for example) looks different from sending ETH directly to a wallet. The actual transfer to the end recipient often happens as an internal transaction — triggered by the contract execution, not your original transaction directly. Block explorers surface these under "Internal Transactions" or "Token Transfers" in a separate tab. If you're trying to verify that someone received tokens from a swap, you may need to check there, not the main transaction page.
Value
How much ETH moved in the transaction itself. For token transfers via a smart contract, the Value field may show 0 ETH — the token movement happens through contract execution, not the base ETH transfer. This trips people up frequently. A swap on Uniswap that moves $1,000 worth of tokens can show 0 ETH in the Value field. That doesn't mean nothing moved; it means the ETH transfer component was zero.
Transaction Fee
Gas used multiplied by the gas price paid, denominated in ETH. This goes to the validator (with a portion burned under EIP-1559). It doesn't go to the recipient.
Gas Price
The fee per unit of computational work. After EIP-1559, this breaks into base fee — burned, set by the protocol — and priority fee, the tip paid to the validator. Higher tip typically means faster inclusion during congestion.
Input Data
Empty for plain ETH transfers. For contract interactions, it contains the encoded function call: which function was triggered and with what parameters. Block explorers decode this for verified contracts. On Etherscan, you'll see something like "Swap Exact ETH For Tokens" on a Uniswap transaction. For unverified contracts, you get raw hex data, which requires either manual decoding or an external tool.
The Bitcoin Difference
Bitcoin uses the UTXO model, which changes how transactions display significantly.
Instead of a single "From" and "To" address, you see inputs — the UTXOs being consumed — and outputs — the UTXOs being created. A single transaction can draw from multiple inputs across different addresses, and produce multiple outputs: one to the recipient, one back to the sender as change.
The fee isn't listed directly. It's implicit: the difference between total input value and total output value is what miners claim. If inputs sum to 0.10001 BTC and outputs sum to 0.10000 BTC, the fee was 0.00001 BTC.
On Mempool.space or a Bitcoin block explorer, the fields to focus on:
- Inputs: Which addresses funded the transaction, and how much
- Outputs: Where the funds went (including change back to the sender)
- Size: Transaction size in virtual bytes (vBytes), which determines the fee rate
- Fee rate: Satoshis per vByte — the competitive metric during mempool congestion
- Confirmations: Blocks added since inclusion
The transaction stays Unconfirmed until included in a block. After that, each new block adds a confirmation.
Where Constraints Live
Block explorers aren't standardized. Etherscan, Arbiscan, Basescan, and various chain-specific explorers show roughly the same data, but layout and labeling differ. Some newer or smaller chains have limited explorer support, which can make raw data harder to read without direct node access.
One thing that doesn't change: historical transaction data is permanently on-chain. Nothing gets deleted. Accessing it requires either a block explorer (convenient, but centralized infrastructure) or querying an archive node directly (decentralized, technically demanding). For most practical verification needs, a block explorer is the right tool.
What's Changing
Block explorers are getting better at decoding complex transactions. Etherscan's transaction decoder now shows human-readable function calls for verified contracts. Wallets like Rabby and simulation tools like Tenderly let you preview what a transaction will do before you sign — surfacing decoded inputs and outputs without needing to interpret hex.
The direction is toward readability for non-technical users. The underlying structure hasn't changed and won't. Understanding the raw fields remains useful even as the UX improves, because the abstractions sometimes obscure what's actually happening.
Confirmation Signals
The mechanism here is stable. The positive signal to watch: contract verification rates on Etherscan continue rising, and wallet-level transaction simulation is becoming a standard feature rather than a developer tool. Both trends make transaction interpretation easier without changing the underlying data model.
What Would Break This
Nothing structural would make transactions unreadable — the on-chain data is immutable. The practical failure mode is using a block explorer that doesn't support a specific chain, which means falling back to the chain's native explorer or querying the RPC directly. For chains with poor explorer support, this can be genuinely inconvenient.
Timing Perspective
Now: Transaction literacy is immediately useful — verifying transfers, checking status, investigating failed transactions. This isn't future-oriented research; it's functional fluency for anyone using crypto today.
Next: As more interactions involve smart contracts (swaps, lending, staking), the distinction between direct transfers and contract-triggered internal transactions becomes increasingly relevant to understand.
Later: Native wallet transaction previewing will likely abstract most of this for most users eventually. But the underlying data will remain as described, and the ability to read it directly stays valuable for edge cases.
Boundary Statement
This post explains what the fields in a blockchain transaction record mean. It doesn't cover tax treatment, how to reconstruct full transaction history across multiple chains, or how to interpret unverified contract bytecode. For smart contract interactions, decoding input data assumes the contract is verified on the relevant block explorer — unverified contracts require separate tooling.
The data reads as described. What you do with that reading is a separate question.
