DEV Community: Jerome Barton

How Block Explorers Reconstruct Transaction Histories

Jerome Barton — Wed, 09 Sep 2026 15:12:28 +0000

Block explorers reconstruct transaction histories by indexing blocks, receipts, logs, and execution traces, then decoding those records into address- and protocol-level events.

Why a transaction history has to be rebuilt

An Ethereum Network node can answer questions about a transaction hash, block, receipt, or log filter, but it does not provide a canonical “show me every transaction involving this address” query. An explorer therefore walks through blocks, stores the results in searchable tables, and adds meaning afterward.

The transaction supplies the sender, recipient, calldata, value, nonce, and position. Its receipt supplies the execution status, gas used, block placement, and logs that survived execution. A history page is an indexed interpretation of those pieces, not a record stored on-chain as a ready-made timeline.

Way one: index transactions and event logs

The efficient method is to scan ordinary transactions and receipts, then use emitted events as the explorer’s main evidence.

Store each block, transaction, and receipt with its block hash and transaction index.
Read receipt logs in execution order and filter them by contract address and topics.
Decode calldata and event data with the relevant contract ABI, turning hexadecimal values into token transfers, approvals, swaps, or governance actions.

This works especially well for ERC-20 activity. A Transfer event identifies the token contract, sender, recipient, and amount; indexed parameters become searchable topics, while the remaining values sit in ABI-encoded data. The explorer can then attach token symbols and decimals from contract metadata.

The limitation is equally important: a log records what a contract deliberately emitted, not every operation the EVM performed. A native ETH transfer may produce no event. A non-standard token may omit the expected event. Logs created inside a reverted call disappear with that call. A router transaction can therefore contain a useful sequence of token movements while still hiding the exact call path that produced them.

That is why a Frax Swap transaction can appear as several token movements rather than one simple “swap” row.

The same decoding pattern applies when examining Frax Swap activity.

Way two: trace the execution

Tracing reconstructs the call tree by replaying a transaction through an execution client. Instead of relying only on emitted events, the explorer asks which contract called which other contract, with what value, gas, calldata, and result.

A trace can expose a router calling a pool, the pool calling a token contract, and a nested call failing before the outer transaction reports failure. It can also reveal native-value transfers that have no ERC-20-style event. This makes traces valuable for internal transactions, contract creation, proxy routing, and debugging an apparent mismatch between balances and logs.

Tracing costs more than log indexing. It requires tracing support from the node and, for old transactions, access to the historical state needed to replay them. Providers may prune that state, restrict trace methods, or return different shapes depending on client and configuration. Trace output is reconstructed execution data; the block, transaction, receipt, and logs remain the primary consensus records.

Where the line falls

Use logs when the question is “which assets or protocol events were recorded?” Use traces when the question is “what call sequence caused this result?”

For an Automated Market Maker, logs usually give the cleanest user-facing answer: tokens in, tokens out, pool address, and amounts. A Balancer Protocol transaction, for example, may pass through a Vault and several pool balances; the logs can summarize those movements, while a trace explains the nested route and any intermediate calls.

The two methods are complementary, but they are not interchangeable. A log-only explorer is fast and scalable, yet can miss silent native transfers and unusual contracts. A trace-first explorer is richer, yet slower, more expensive, and dependent on historical replay.

What to build on

A reliable indexer keeps both layers. Use transactions, receipts, and logs for the canonical searchable history; add traces when the event record cannot answer the user’s question. Key records by chain ID, block hash, transaction index, and log index rather than timestamp alone. Decode with the ABI valid for that contract at that block, and rescan a small range when a chain reorganization replaces blocks.

The practical verdict is simple: logs tell you what contracts announced, while traces tell you how execution got there. A block explorer reconstructs trustworthy histories by knowing which of those two answers the application actually needs.</

How Wallets Display Assets From Other Networks

Jerome Barton — Tue, 08 Sep 2026 12:26:06 +0000

A wallet displays assets from another network by querying that network’s blockchain and matching the result to token metadata; it does not move the assets into the wallet’s current network.

That distinction matters as soon as a bridge transaction finishes on one side but the new token is missing from the screen. The asset may already exist on the destination chain while the wallet is still looking at the source chain, an unsupported RPC endpoint, or the wrong token contract.

What the wallet is actually reading

On EVM networks, an account is usually represented by the same hexadecimal address on several chains, but each chain keeps separate balances and contract state. The balance at an address on Ethereum is not the balance at that address on Arbitrum One. A wallet has to ask each network independently.

It does this through an RPC endpoint. For a native coin, the wallet can request the address balance directly. For an ERC-20 token, it calls the token contract’s balanceOf function for that address. It may then call functions such as symbol, name, and decimals, or obtain that information from a token registry. NFT balances are often supplied through an indexing service because checking every token contract one by one would be too slow for a normal portfolio screen.

The wallet therefore needs three pieces to show an asset correctly: the network, the contract address, and readable metadata. The ticker symbol is not enough. “USDC” on one network can be a different contract from “USDC” on another, and a malicious token can copy a well-known name and logo. The contract address, tied to the chain ID, is the useful identity.

Many modern wallets query several supported networks in the background and combine the results into a portfolio view. Others show only the currently selected network. The network selector is a filter on the data being read, not a switch that transfers ownership or consolidates balances.

Outside the EVM world, the same idea becomes less interchangeable. A Solana account and an EVM account use different address formats, transaction models, and token standards. A wallet can present them in one app, but it still uses chain-specific account information and RPC methods underneath. WalletConnect Protocol also keeps chains explicit: a dapp connection approves particular namespaces, accounts, methods, and chains. Connecting a wallet does not give the dapp a universal view of every balance or authorize transactions on every network.

Why a bridged asset can seem to disappear

A bridge normally involves two separate state changes. On the source network, tokens may be locked in a bridge contract or burned. A message, proof, or validator decision then allows the destination side to release or mint a representation of those tokens. The wallet cannot display the destination balance until the destination transaction has executed and the wallet’s RPC or indexer can see it.

This creates several ordinary waiting points. The source transaction may be confirmed while the bridge message is still being processed. The destination transaction may be complete while the portfolio indexer has not refreshed. Or the wallet may be showing Ethereum when the newly minted representation is on Arbitrum One.

Before assuming that funds are lost, check the transaction on the relevant explorers and verify the destination chain. If the destination transaction succeeded but the token is absent, importing the token by its verified contract address can make it visible. Importing a token changes the wallet’s display list; it does not create a balance, alter the contract, or recover funds sent to another address.

An EVM address can also receive tokens on a network the wallet does not currently support. The private key may still control that address, but the app has no approved network configuration or reliable data source with which to show it. Adding an arbitrary RPC can make the balance readable, but it also means trusting that RPC and checking that the chain ID and token contract are correct.

Network: confirm the chain name and chain ID, not just the wallet account.
Contract: compare the token address with the bridge’s official destination contract.
Transaction: distinguish source confirmation from destination execution.
Gas: keep some of the destination network’s native asset for later transfers or approvals.
Representation: check whether the token is canonical, wrapped, or a bridge-issued version.

Display is not the same as usability

A visible balance proves that the wallet can read a token on a particular chain. It does not prove that a dapp supports that chain, that the token has usable liquidity, or that the asset can be sent without paying destination gas. A bridge-issued token can be perfectly real and still trade poorly if few pools or market makers support it.

This is where the cost of a bridge becomes practical rather than theoretical. The user may pay source gas, a bridge fee, destination gas, and sometimes a swap fee. The larger cost is often attention: selecting the correct chain, checking the contract, waiting for finality, and approving a token contract before a later transaction can use it.

Before multi-network portfolio views, the routine was more manual: open a block explorer for each chain, switch the wallet network, paste the token contract into the import dialog, and keep separate notes about which representation was held where. Aggregated wallet screens remove much of that friction, but they can also hide the chain boundary that still governs every transaction.

What to do after the asset appears

Once the destination balance is visible, decide whether the next action is a transfer, a swap, or another bridge. A swap changes the token; a bridge changes the network on which the token is represented. Some products combine both operations, but the transaction still has distinct source and destination details.

Uniswap Protocol, for example, can provide liquidity and routing on a supported chain, but a swap there is not automatically a bridge to another network. A quote from Paraswap is useful only when its source chain, destination chain, token contracts, amount, and required gas asset match what the wallet is displaying.

For the actual swap, use Paraswap for the transaction.