Requirements
The examples in this guide call the debug JSON-RPC endpoints directly withcurl. You do not need an SDK or other libraries. To pretty-print the JSON responses, you can install jq:
What you can trace
Transaction execution
- Step-by-step opcode execution
- Contract call hierarchy
- Gas consumption breakdown
- State changes and storage access
Contract interactions
- Cross-contract calls and returns
- Event emission analysis
- Precompile usage tracking
- External library calls
Performance analysis
- Gas optimization opportunities
- Bottleneck identification
- Cache hit and miss patterns
- State access efficiency
Security analysis
- Suspicious operation detection
- Reentrancy pattern analysis
- Access control verification
- Vulnerability scanning
Available tracing methods
Transaction analysis example
This example traces an ERC-20 transfer transaction:- Transaction Details
- Basic Trace
- Gas Analysis
Debugging failed transactions
Use these steps to analyze and fix transaction failures:Step 1: Identify the problem
Step 2: Trace the execution
Step 3: Fix and test
Common debugging scenarios
Transaction reverted
Problem: The transaction failed with a revert. Solution: UsecallTracer to find the exact revert reason.
Out of gas
Problem: The transaction ran out of gas. Solution: Use the gas analysis tracer to optimize gas usage.Unexpected behavior
Problem: The transaction succeeded, but the result is wrong. Solution: Use the opcode tracer for step-by-step analysis.Slow performance
Problem: The transaction uses too much gas. Solution: Use the state access tracer to find inefficiencies.Quick reference
Essential commands
Common tracers
callTracer: Contract call hierarchyopcodeTracer: Opcode-level execution- Custom JS: Custom analysis logic
Pre-baked trace cache
RPC nodes can optionally pre-compute and cachedebug_trace* results in the background. The node then serves trace requests from a local on-disk cache instead of re-executing the block live on every call. You configure this opt-in feature through [evm] fields in app.toml. It is recommended for RPC nodes only.
When the feature is enabled, a background worker re-executes each committed block with the configured tracers. It stores the results in a Pebble database at <home>/data/trace_db. These methods serve results from this cache on a cache hit. Otherwise, they fall through to live re-execution:
debug_traceTransactiondebug_traceBlockByNumberanddebug_traceBlockByHash
When the cache is used
The node serves a request from the cache only when trace baking is enabled and the request uses a bakeable tracer configuration:- The tracer is one of
callTracer,prestateTracer, orflatCallTracer. - The request does not include a custom
tracerConfig. A per-calltracerConfig(for example,{"withLog": true}) is not part of the cache key. Any custom tracer config makes the request un-bakeable, so it falls through to live re-execution.
Configuration
These[evm] fields in app.toml control trace baking:
Removed legacy trace filters
The legacy
*ExcludeTraceFail endpoints have been removed. For block tracing, use debug_traceBlockByNumber or debug_traceBlockByHash. For EVM receipts, use eth_getTransactionReceipt. There is no block or filter method to discover synthetic logs from Cosmos-originated transactions. If you already know a synthetic transaction hash, enable sei_getTransactionReceipt to get its receipt and logs.Next steps
- JavaScript tracers: Custom analysis scripts
- Troubleshooting: Common issues and solutions
Start with
callTracer for general debugging. Then use specialized tracers for specific analysis needs.