Reading debug_traceTransaction Output

Why this matters

debug_traceTransaction is the single most powerful tool for understanding what a transaction actually did — every opcode, every stack frame, every state change. It's how every block explorer renders 'internal transactions' and how every security researcher reconstructs an exploit. Learning to read this output well is a 10× force multiplier for any on-chain investigation.

Demo

Get a structured trace from a real transaction and walk through it.

Try it yourself

1. Pick a recent Uniswap v2 swap tx hash and run cast run --rpc-url $RPC <tx> — observe the call tree.
2. Switch tracer from callTracer to prestateTracer on the same tx and identify every account whose storage was touched.
3. Identify the gas consumed in each subcall and find the single subcall that dominates gas (usually the SSTORE-heavy one).

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain what `debug_traceTransaction` does and why it's not a 'normal' eth_* RPC method.

2. Why it works (the mechanism)

Walk me through the difference between callTracer, structLog, and prestateTracer — what each emits and when you'd choose one.

3. Advanced — application & what's next

Given a transaction that 'mysteriously' reverted with a known function selector and known calldata, walk me through a structured debugging approach using debug_traceTransaction to isolate the exact opcode and state condition that triggered the revert.

References

• Geth docs — debug_traceTransaction
• Foundry book — cast run