Requirements
The examples in this guide call the debug JSON-RPC endpoints directly withcurl — no SDK or additional libraries are required. Optionally install jq to pretty-print the JSON responses:
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/miss patterns
- State access efficiency
Security Analysis
- Suspicious operation detection
- Reentrancy pattern analysis
- Access control verification
- Vulnerability scanning
Available Tracing Methods
Transaction Analysis Example
Tracing an ERC-20 transfer transaction:- Transaction Details
- Basic Trace
- Gas Analysis
Debugging Failed Transactions
Steps to analyze and resolve transaction failures:Step 1: Identify the Problem
Step 2: Trace the Execution
Step 3: Fix and Test
Common Debugging Scenarios
Transaction Reverted
Problem: Transaction failed with revert Solution: UsecallTracer to find the exact revert reason
Out of Gas
Problem: Transaction ran out of gas Solution: Use gas analysis tracer to optimize gas usageUnexpected Behavior
Problem: Transaction succeeded but wrong result Solution: Use opcode tracer for step-by-step analysisSlow Performance
Problem: Transaction uses too much gas Solution: Use state access tracer to find inefficienciesQuick 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 so that trace requests are served from a local on-disk cache instead of re-executing the block live on every call. This is an opt-in feature configured through new [evm] fields in app.toml and is recommended for RPC nodes only.
When enabled, a background worker re-executes each committed block with the configured tracers and stores the results in a Pebble database at <home>/data/trace_db. The following methods serve from this cache on hit, and otherwise fall through to live re-execution:
debug_traceTransactiondebug_traceBlockByNumberanddebug_traceBlockByHash
When the cache is used
A request is only served from cache when trace baking is enabled and the request uses a bakeable tracer configuration:- The tracer is one of
callTracer,prestateTracer, orflatCallTracer. - No custom
tracerConfigis supplied. A per-calltracerConfig(for example{"withLog": true}) is not part of the cache key, so any custom tracer config makes the request un-bakeable and it falls through to live re-execution.
Configuration
Trace baking is controlled by these[evm] fields in app.toml:
Removed legacy trace filters
The legacy
*ExcludeTraceFail endpoints have been removed. Use debug_traceBlockByNumber or debug_traceBlockByHash for block tracing and eth_getTransactionReceipt for EVM receipts. There is no block or filter method for discovering synthetic logs from Cosmos-originated transactions. If you already know a synthetic transaction hash, enable sei_getTransactionReceipt to retrieve 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.