Find the first failing frame and the callers that handled it.
LET’S PICTURE IT
A chain of forwarded reports needs a timeline showing who encountered the original problem.
SEE IT FOR YOURSELF
Follow a revert and decode its error dataStep 1 / 4
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.The contract rejects this request. State changes in the reverted call are rolled back, while work already consumed can still cost gas.A common Error(string) begins with selector 08c379a0. This example then encodes the message Not enough tokens.A decoder can recognize the supplied error shape. Identifying the true cause and source still needs the call context, code and state.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
List the call tree
Record A calling B and B calling C, including the relevant inputs and execution context. A flat transaction destination does not describe the whole nested interaction.
Locate the first failure
Find the frame where execution first reverts or halts exceptionally. Its immediate return bytes can differ from the payload eventually exposed by the outermost frame.
Track each response
A parent can catch, transform, ignore or propagate the child failure. Read both the success flag and returned bytes at each boundary before assigning a root cause.
Separate trace results from chain inclusion
A simulation trace explains a run with particular state and settings. It is not automatically proof of a finalized transaction or a guarantee that a later run follows the same path.
Inspect the example
A → B → C
C: reverts with Error("No tickets left")
B: catches C and reverts with its own custom error
A: forwards B’s bytes
Final bytes describe B’s error; C still explains an earlier failure.
A simplified trace showing why the final payload is not the complete failure history.