Skip to main content

Requirements

The examples in this guide call the debug JSON-RPC endpoints directly with curl. You do not need an SDK or other libraries. To pretty-print the JSON responses, you can install jq:
Debug tracing is your primary tool to understand how EVM transactions execute on Sei. With it, you can analyze transaction flow, optimize gas usage, debug smart contract interactions, and troubleshoot production issues.

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:
Response:

Debugging failed transactions

Use these steps to analyze and fix transaction failures:

Step 1: Identify the problem

Step 2: Trace the execution

Response:

Step 3: Fix and test

Common debugging scenarios

Transaction reverted

Problem: The transaction failed with a revert. Solution: Use callTracer 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 hierarchy
  • opcodeTracer: Opcode-level execution
  • Custom JS: Custom analysis logic

Pre-baked trace cache

RPC nodes can optionally pre-compute and cache debug_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_traceTransaction
  • debug_traceBlockByNumber and debug_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, or flatCallTracer.
  • The request does not include a custom tracerConfig. A per-call tracerConfig (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.
Requests that use the struct logger (no tracer), a JavaScript tracer, or any other named tracer always run live.

Configuration

These [evm] fields in app.toml control trace baking:
Trace baking adds a persistent on-disk store at <home>/data/trace_db and increases disk usage. The node flushes the store’s write-ahead log when it shuts down cleanly.

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

  1. JavaScript tracers: Custom analysis scripts
  2. Troubleshooting: Common issues and solutions
Start with callTracer for general debugging. Then use specialized tracers for specific analysis needs.