Avalanche
debug_traceTransaction
The debug_traceTransaction method recreates the exact execution state of a historical transaction, providing detailed opcode-level trace information. It reproduces the original state at the specific block where the transaction was executed, allowing for complete analysis of transaction execution flow, stack operations, memory changes, storage modifications, and gas consumption.
Unlike other transaction retrieval methods that only provide basic transaction data, debug_traceTransaction offers introspection into the internal execution of the EVM during transaction processing.
Use Cases
- Failed Transaction Analysis: Determine exactly why a transaction failed by examining the precise instruction that caused the revert and the EVM state at that point
- Smart Contract Debugging: Investigate unexpected behavior in contract execution by examining the complete execution pathway and state changes
- Gas Usage Optimization: Identify expensive operations and inefficient code patterns by analyzing gas consumption per opcode
- Security Auditing: Detect potential vulnerabilities by analyzing the exact execution flow and state transitions during transaction processing
- Transaction Verification: Confirm that a contract behaved as expected for a specific transaction by reviewing all operations performed
- Contract State Inspection: View the exact changes made to contract storage during transaction execution
- Forensic Investigation: Reconstruct transaction execution for investigating security incidents or analyzing historical events
- Call Graph Analysis: Visualize the execution flow between contracts including internal function calls and message values
- Finding State Inconsistencies: Identify unexpected state changes during complex contract interactions
- Recreating Execution Context: Reproduce the exact blockchain environment that existed when the transaction executed
Method Details
This method traces the transaction identified by its hash, providing opcode-level execution details.
Response Example (Default Tracer)
Response Example (callTracer)
Common Issues Identified Through Tracing
- Out of gas errors
- Stack underflows or overflows
- Invalid opcode execution
- Failed assertions or require conditions
- Unexpected reverts
- Memory allocation issues
- Unexpected contract state
- Transfer failures
- Access control issues
- Logic errors
Available Tracers
- Default Tracer: Returns structured logs for each opcode
- callTracer: Shows call graph between contracts
- prestateTracer: Shows state before transaction execution
- 4byteTracer: Collects function selectors
- noopTracer: Discards all information
- Custom JavaScript Tracers: Create your own tracer logic
Trace Options
You can tune performance and output by configuring these options:
- Disable stack, memory, or storage capturing for faster execution
- Use custom timeout for complex transactions
- Apply custom tracer configurations for specific analysis needs
Performance Considerations
- Tracing complex transactions can be resource-intensive and slow
- Large contracts with many operations may produce very large response payloads
- Using options to disable certain captures (memory, storage, stack) can improve performance
- Consider using a specific custom tracer for targeted analysis rather than capturing everything
- Tracing transactions that create contracts with large initialization code can be particularly intensive
- Transactions with many internal calls or high call depth require more resources to trace
Important Notes
- This method requires debug APIs to be enabled on the node (usually with
--http.api=debugflag) debug_traceTransactionprovides more detailed information thantrace_transaction- For accurate results, you need access to the historical state at the block where the transaction occurred
- Archive nodes are required for tracing older transactions
- Some clients may not support all tracer types
- Custom JavaScript tracers are only available on Geth and some Geth-compatible clients
- This method will replay the transaction exactly as it occurred, including any side effects
- The trace does not include events/logs (these must be queried separately)
- Some operations like
BLOCKHASHhave their results from the original execution cached and reused - Using this method on transactions in very old blocks may result in state inconsistencies on some nodes
See also
- debug_traceCall - Execute a call without generating a transaction and return the trace data
- debug_traceCallMany - Execute multiple calls without generating transactions and return trace data
- trace_transaction - Return trace data for a specific transaction
- eth_getTransactionByHash - Retrieve basic transaction information by hash
- eth_getTransactionReceipt - Get transaction receipt information by hash
Parameters
32-byte transaction hash
JSON tracer options: { tracer?, timeout?, tracerConfig? }