Ethereum transactions look simple until they don’t. At first glance a transaction is “from A to B,” gas paid, and status success or fail. But once you scratch the surface you hit logs, internal transfers, contract calls, and the messy reality of DeFi interactions—where one user action spawns a dozen on‑chain steps. This guide walks through how transactions are actually represented on chain, what to watch for when tracking DeFi flows, and concrete tips for handling ERC‑20 token movements as a developer or power user.
Short version: block explorers are your friend. The one I go to most is etherscan. It surfaces tx receipts, event logs, decoded input, and internal txs in ways JSON-RPC alone won’t. But explorers can only infer so much; sometimes you need to dig into logs, verify contracts, or simulate calls to really understand what happened.
How ETH transactions are structured (the pragmatic view)
Think of a transaction as two layers. The outer layer is the envelope: nonce, gas price/limit, to/from, value, and signature. The inner layer is the payload: calldata for a contract call, which only has meaning when interpreted by that contract’s ABI. Simple ETH transfers put value in the envelope and that’s it. Contract interactions carry calldata and the contract’s code decides what to do next.
When a contract executes it can emit events (logs) and call other contracts. Those nested calls are called internal transactions; they’re not top‑level transactions on the chain, but they change state and move tokens. Explorers reconstruct them by tracing execution, which is handy—but remember it’s a reconstruction. If you’re relying on an explorer for compliance or accounting, cross‑check the raw receipt and logs.
ERC‑20 token movements: what to watch for
ERC‑20 token transfers can happen in three broad ways: direct Transfer events, contract bookkeeping (balance updates without events, rare but possible in broken tokens), and proxy‑style behavior where a contract moves tokens on behalf of a user. The only reliable on‑chain evidence that a token moved is either a Transfer event or the subsequent reading of balances at two snapshots.
Never assume reading transferFrom in the ABI equals a transfer happened. The function can revert, or the contract might be a non‑standard implementation. Always check the transaction receipt for the Transfer event. If you need absolute certainty for accounting, sample the balances (via eth_call) before and after the block—this avoids being fooled by token contracts that fail to emit events correctly.
DeFi flows: follow the logs, not the UI
DeFi actions—swap, deposit, borrow—usually result in multiple on‑chain operations. A single “swap” on a UI may call a router contract that calls pool contracts, transfers tokens, and updates internal accounting. Each of those steps emits logs. To reconstruct a user’s net economic position, aggregate relevant events across the transaction’s logs, and interpret them relative to the involved contract ABIs.
One practical pattern: identify the router contract (often the “to” address for the user’s tx), then trace internal calls made by that contract in the receipt. Look for Transfer events and any protocol‑specific events (like Swap, Mint, Burn). Those tell you who lost which token and who gained which token. For composable actions (e.g., flash swaps + lending + liquidation), you may need to correlate events across multiple contracts and even multiple transactions in the same block.
Pending transactions and mempool visibility
Pending txs live in the mempool before inclusion. Observing the mempool is essential if you need to detect front‑running or sandwich attacks. Tools that subscribe to a node’s pending transaction stream let you inspect calldata and gas price bumping. But beware: mempool visibility varies by node and network—some nodes filter or do not relay certain txs, and private relays can hold txs out of your view.
If you’re building a monitoring system, run multiple nodes or use diversified providers, and consider subscribing to specialized mempool services. For forensic work, timestamping when a tx first appears across multiple peers helps build a clearer story.
Gas, reverts, and error decoding
A reverted transaction still consumes gas up to the point of the revert. The receipt shows status=0 and the gasUsed, but it doesn’t always include a human‑readable revert reason unless the tx returned one and you decode it. Modern tools decode revert reasons by analyzing the returned data according to the ABI for Error(string) or custom error types.
When a tx reverts without a reason, simulate the call locally (eth_call with the same calldata at the block number) to force the node to return the revert data. This helps when a transaction fails only under certain on‑chain conditions or stateful race conditions.
Practical tooling and patterns for developers
Use a mixed approach: RPC calls for authoritative state, explorer APIs for human‑friendly decoding, and local replication for debug. Here are concrete tips:
- When auditing token flows, pull raw receipts (eth_getTransactionReceipt), parse logs by event signature, and validate balance deltas with eth_call snapshots.
- Keep a local ABI registry for the contracts you monitor—this makes log decoding deterministic and faster than guessing via heuristics.
- Monitor internal transactions (traces) if you need full execution detail. Traces are heavier but reveal nested transfers that receipts alone don’t show.
- For front‑running detection, correlate mempool observations with block inclusion time and gas price changes; timestamp everything.
Common pitfalls and how to avoid them
Relying solely on decoded input from an explorer can mislead. For example, some ERC‑20s implement non‑standard return values (e.g., return nothing for transfer), causing tooling that expects boolean returns to misclassify tx outcomes. Also, wrapped tokens, cross‑chain bridges, and proxy patterns introduce layers where a single transfer triggers multiple on‑chain events across contracts.
To avoid errors: prefer explicit event parsing, validate on‑chain state changes, and build tests that simulate typical DeFi call paths. And keep an eye on token approvals—approvals themselves are not transfers, but they enable later transfers that your monitoring must catch.
FAQ
Q: How do I reliably detect ERC‑20 transfers?
A: Watch Transfer events and validate with balance snapshots. If you need extra confidence, query balances before and after the block that includes the tx. Event parsing is usually enough for most dashboards, but for audits do the balance delta too.
Q: Can I trust explorer “internal transactions” lists?
A: They’re useful but treat them as derived data. For critical systems, fetch raw traces from a full node and rerun the execution trace yourself to ensure nothing was missed or misattributed.
Q: What about token transfers executed through permit or meta‑transactions?
A: Those patterns still result in on‑chain state changes and typically emit Transfer events. But because the actor stored in the tx can be a relayer, correlate approval and signature usage events to map the actual economic actor versus transaction sender.
