Reading a Transaction Trace

The transaction page on an explorer shows a summary. A trace shows the execution: every contract called, in order, with inputs, outputs and gas consumed.

What a trace contains

The call tree. The initial call, and every internal call it made, nested to show which called which.

Inputs and outputs for each call, decoded where the contract is verified.

Gas consumed at each level.

The result of each call: success, revert, or out of gas.

Value transferred in each internal call, including movements the summary may not show.

Why it is more informative than the summary

A single transaction can touch a dozen contracts. A swap routed through an aggregator calls the router, which calls one or more pools, each of which calls token contracts.

The summary shows the net result. The trace shows the route, which is where the cost and the failure live.

The questions a trace answers

Why did this fail. The trace shows which call reverted and, where the contract provides one, the revert reason.

Where did the gas go. Which internal call consumed it, which frequently reveals that an unexpected path was taken.

What route did my swap take. Which pools, in what order, and what each leg cost in slippage.

Did this contract do something I did not expect. Internal transfers that do not appear in the summary are visible here.

Where to find one

Most major explorers offer a trace or internal transactions tab. Some require the network to have tracing enabled, which not all do.

Dedicated transaction inspection tools provide richer traces with decoded parameters and simulated alternatives.

The practical uses

After a failed transaction, to determine the cause before retrying.

After an unexpected result, to establish what actually executed.

Before signing, where the tool supports simulation. Simulating a pending transaction and reading the resulting trace is the strongest available check on what a request will do, and it is what transaction simulation features in wallets are doing behind the interface.

The limitation

A trace of a verified contract is readable. A trace through unverified contracts is a sequence of addresses and hex.

That is another reason unverified contracts are worth avoiding: not only can you not read the code, you cannot read what happened when you interacted with it.

For most users

You will not need this often. When something goes wrong, it is the difference between knowing what happened and guessing, and it is available to anyone for free.

For the ordinary path, where funds move between a venue such as a venue that supports immediate withdrawal and a wallet, the transaction is simple and the summary is sufficient. Traces matter for contract interaction, which is where the complexity and the failures concentrate.