trace_call

The trace_call method allows you to execute a new message call and get a detailed trace of its execution without adding the transaction to the blockchain. This is like eth_call but with detailed step-by-step execution traces.

Use Cases

• Debug complex contract interactions before sending transactions
• Analyze gas consumption patterns without spending actual gas
• Test smart contract functions with different parameters
• Simulate transactions in different blockchain states
• Detect potential security vulnerabilities in contract code
• Understand contract execution flows and state changes
• Verify contract behavior under specific edge case conditions
• Create contract execution visualization tools
• Perform static analysis of contract code
• Test transaction reverts and error conditions safely

Method Details

This method simulates a transaction and returns detailed traces of its execution.

Response Example

{
	"jsonrpc": "2.0",
	"id": 1,
	"result": {
		"output": "0x",
		"stateDiff": null,
		"trace": [
			{
				"action": {
					"callType": "call",
					"from": "0x6f1fb6efdf50f34bfa3f2bc0e5576edd71631638",
					"gas": "0x1dcd11f8",
					"input": "0xa67a6a45000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000",
					"to": "0x1e0447b19bb6ecfdae1e4ae1694b0c3659614e4e",
					"value": "0x0"
				},
				"error": "Reverted",
				"subtraces": 0,
				"traceAddress": [],
				"type": "call"
			}
		],
		"vmTrace": null
	}
}

Call Types

The callType field in the trace action indicates the type of call:

• call: Standard call between addresses
• staticcall: Read-only call (cannot modify state)
• delegatecall: Call that keeps the caller's context
• callcode: Legacy call type (deprecated)

Trace Types

The type field in the trace indicates the type of operation:

• call: A message call
• create: A contract creation
• suicide: A contract self-destruct (SELFDESTRUCT opcode)

Understanding traceAddress

The traceAddress field indicates the position in the call tree:

• Empty array ([]) for top-level calls
• An array of indices showing the path through nested calls
• Helps you track the exact execution path through complex interactions

Response Example with Successful Call

Here's an example response from trace_call:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "output": "0x0000000000000000000000000000000000000000000000000000000000000001",
    "stateDiff": { /* state changes */ },
    "trace": [
      {
        "action": {
          "callType": "call",
          "from": "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
          "gas": "0x1dcd12f8",
          "input": "0xa9059cbb0000000000000000000000002710000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a",
          "to": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b",
          "value": "0x0"
        },
        "result": {
          "gasUsed": "0x765",
          "output": "0x0000000000000000000000000000000000000000000000000000000000000001"
        },
        "subtraces": 1,
        "traceAddress": [],
        "type": "call"
      },
      {
        "action": {
          "callType": "call",
          "from": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b",
          "gas": "0x1dcd0393",
          "input": "0x",
          "to": "0x2710000000000000000000000000000000000000",
          "value": "0xa"
        },
        "result": {
          "gasUsed": "0x0",
          "output": "0x"
        },
        "subtraces": 0,
        "traceAddress": [0],
        "type": "call"
      }
    ],
    "vmTrace": { /* detailed VM execution information */ }
  }
}

Differences from eth_call

While both trace_call and eth_call perform simulated calls:

• trace_call provides detailed execution traces not available in eth_call
• trace_call can return several types of traces (operations, VM steps, state changes)
• trace_call gives more information for debugging and analysis
• eth_call is more lightweight and standard across all Ethereum clients
• trace_call supports historical block state simulation

Performance Considerations

• Tracing is computationally intensive, especially with all trace types enabled
• vmTrace and stateDiff particularly increase response size and computation time
• Consider requesting only the trace types you need
• For complex contracts, responses may be very large
• May timeout on public nodes or rate-limited endpoints
• Response time increases with the complexity of the transaction
• Consider using batch requests if tracing multiple calls
• For production applications, dedicated infrastructure is recommended

Important Notes

• This method requires trace APIs to be enabled on the node
• Not all clients support this method (primarily Geth with --gcmode=archive and OpenEthereum/Nethermind)
• The method doesn't modify the blockchain or use real gas
• Gas estimates may differ slightly from actual transactions due to simulation details
• Different clients may return slightly different trace formats
• Reverted transactions will include trace information up to the revert point
• For historical blocks, the node must have archive data for that state
• The stateDiff response can be very large for transactions that modify many storage slots
• Tracing against mainnet might be unavailable on most public RPC providers
• Traces show the actual execution path, not all possible paths

See also

• trace_transaction - Retrieve trace for an existing transaction
• trace_filter - Filter and search for traces across multiple blocks
• trace_block - Get traces for all transactions in a block
• eth_call - Similar method but without detailed trace information
• debug_traceCall - Alternative trace method with different tracing options