How to read a blockchain transaction
Inputs, outputs, fees and change on Bitcoin; calldata, logs and token transfers on Ethereum: what each field means, and the misreadings that cost people money.
Updated 14 Sept 2026 · Advanced · 4 min read
In short
- A Bitcoin transaction spends whole earlier outputs and creates new ones. The fee is never written down: it is whatever the inputs leave over after the outputs.
- An EVM transaction is a call from an account to an address, with a value and input data. Token movements appear in the event logs, not in the value field.
- Read what a transaction does, not what an interface says it does. Decode it yourself before you sign and after it confirms.
Two models of the same idea
Every blockchain transaction is a signed instruction that nodes check and, once it is in a block, apply to the ledger. Bitcoin and EVM chains model that instruction differently. Bitcoin moves discrete coins, called unspent outputs, from owner to owner. Ethereum and its relatives update account balances and run code. Most misreadings come from applying one model to the other.
Anatomy of a Bitcoin transaction
- Inputs point to earlier outputs by transaction ID and index, and prove the right to spend them with a signature in the input’s witness or script.
- Outputs each lock an amount to a script, which is what an address encodes. An output is later spent in full or stays unspent.
- Sequence numbers and lock time control when a transaction may confirm. A sequence below 0xfffffffe on any input also signals that it can be replaced by fee (RBF).
- Size is measured in virtual bytes, with signature data discounted, which is why SegWit and Taproot inputs cost less to spend.
fee = sum of inputs − sum of outputsOne output in that example is a payment and the other is almost certainly change going back to the sender, because a wallet has to spend whole outputs. The chain does not say which is which. Outsiders have to guess, as address forensics explains; your own wallet knows, because it derived the change address itself.
Check a Bitcoin transaction before you sign
Hardware wallets and multisig setups pass unsigned transactions around as PSBTs (BIP 174), which carry the data a signer needs. Paste a PSBT or a raw transaction into our transaction and PSBT decoder; it runs in your browser and nothing is sent to us.
- Treat every output not marked as your change as money leaving your wallet, and check each address against where you meant to send.
- Compare the fee and fee rate with the current fee levels. A fee far above the market is a classic sign of a mistake.
- Look at the signature hash flags. ALL, or DEFAULT on Taproot, is normal. NONE, SINGLE and ANYONECANPAY let other people change parts of the transaction after you sign.
- Confirm the same outputs and amounts on your hardware wallet’s screen before you approve.
Anatomy of an EVM transaction
- From and nonce: the sending account and its transaction counter. Nonces run strictly in order, so one stuck transaction holds up every later one.
- To: the account being called. For a plain ETH payment it is the recipient; for a token transfer it is the token contract; for a contract deployment it is empty.
- Value: the amount of the chain’s native coin sent. A token transfer usually shows a value of 0.
- Input data, or calldata: for a contract call, the first four bytes are the function selector, taken from a hash of the function’s name and argument types, followed by the encoded arguments.
- Gas: the limit, the amount actually used and the price paid. On layer 2s the fee also covers posting the transaction’s data to Ethereum.
- Status: success or failure. A failed transaction still pays for the gas it used, and none of its other effects happen.
fee = gas used × effective gas price (+ L1 data fee on rollups)Logs, token transfers and internal calls
A token transfer does not change anyone’s ETH balance. It changes a number inside the token contract, which announces the change by emitting an event: a log entry such as Transfer(from, to, amount). Explorers and our transaction lookup build the list of token transfers from those logs. A contract can also send ETH onwards while it runs; those internal transfers appear in execution traces, not as transactions of their own.
Reading one for real
Take a token swap. Paste its hash into the transaction lookup, which finds the chain for you, decodes the method from its selector and lists the token transfers. Then check, in order:
- Status and block. Did it succeed, and in which block?
- To. Is this the router or contract you meant to use?
- Method. A swap should decode as a swap. An approve, permit or setApprovalForAll you did not intend is the most important thing to catch; see token approvals.
- Transfers. Tokens leaving your address should match what you meant to spend, and tokens arriving should come from the verified contracts you expected.
- Fee. What the gas actually cost.
For Bitcoin and EVM transactions alike, the intelligence transaction view adds labels and a risk assessment to every address involved, which tells you who you were dealing with as well as what moved.