Typically,
trace_id for traces are unique, unless there are duplicate transactions on the blockchain. Which may occur for edge cases. Unless otherwise specified, all the EVM-trace data is fetched from debug_traceBlockByNumber from geth client.Table Columns
Unique Key:trace_id
| Column Name | Data Type | Description |
|---|---|---|
| transaction_hash | VARCHAR | Unique identifier of the transaction that this trace belongs to. |
| transaction_index | BIGINT | The position of this transaction in the block that it belongs to. The first transaction has index 0. |
| from_address | VARCHAR | The address of the sending party of this transaction. |
| to_address | VARCHAR | The address of the receiving party of this transaction, typically a contract address for traces. |
| value | VARCHAR | The amount of gas token moved from the from_address to to_address. |
| input | VARCHAR | The bytecode of the call that is made to another smart contract. |
| output | VARCHAR | The bytecode answer the smart contract that was called gives back. |
| trace_type | VARCHAR | The value of the method such as call, create, create2, suicide. |
| call_type | VARCHAR | The type of method such as call, delegatecall, staticcall. Learn more here. |
| reward_type | VARCHAR | Populated when trace_type = reward. Possible values: block, uncle. |
| gas | BIGINT | Gas provided with the trace call, in wei. |
| gas_used | BIGINT | The amount of gas consumed, in wei. |
| subtraces | BIGINT | Number of children traces. |
| trace_address | VARCHAR | The address of the trace within the call graph. |
| error | VARCHAR | Human readable developer error message. Examples: “Out of gas”, “Reverted”, “Bad instruction”, “Bad jump destination”. |
| status | BIGINT | Success status of the trace. Either 1 (success) or 0 (failure). |
| block_timestamp | TIMESTAMP_NTZ(9) | The time when the block that contains this trace was included on the blockchain. |
| block_number | BIGINT | The length of the chain, in blocks. |
| block_hash | VARCHAR | Unique identifier of the block that includes this trace. |
| trace_id | VARCHAR | Unique identifier for this trace. Generated by combining the trace_type, transaction_hash and trace_address. |
| selector | VARCHAR | 4-bytes of the input data. |
| before_evm_transfers | VARIANT | EVM transfers state before the trace execution. (Only applicable for Arbitrum Orbit Chains) |
| after_evm_transfers | VARIANT | EVM transfers state after the trace execution. (Only applicable for Arbitrum Orbit Chains) |
| _created_at | TIMESTAMP_NTZ(9) | Timestamp of the entry creation. |
| _updated_at | TIMESTAMP_NTZ(9) | Timestamp of the entry update. |
Additional Info
Trace Address field different from Etherscan/Explorers
The number of traces Allium has indexed for this transaction is 12, whereas if you count the number of traces that Etherscan has on this page, you’ll notice that it is 11. Etherscan has chosen to leave out certain types of traces and coupled with how trace addresses are generated, it will result in a different trace address numbering scheme. In the example above, the trace in the example as indexed by Allium is{0,0,2,0} whereas on Etherscan/Block Explorer it’s as follows:
