Skip to main content
Schema: tron.core Table: fact_event_logs Type: View

​
What

This table contains raw event logs emitted by smart contracts on the Tron blockchain. Each row represents one event emitted during transaction execution. Events are the primary mechanism for contracts to communicate state changes on-chain.

​
Key Use Cases

  • Tracking raw blockchain events before decoding
  • Filtering by event signature (topic_0) to find specific event types
  • Analyzing smart contract activity and interaction patterns
  • Building custom event decoders for protocols not yet in fact_decoded_event_logs
  • Monitoring specific addresses via indexed parameters (topic_1, topic_2, topic_3)

​
Important Relationships

  • Join with fact_decoded_event_logs: Use tx_hash and event_index for decoded/human-readable event data
  • Join with fact_transactions: Use tx_hash for full transaction context
  • Join with dim_contracts: Use contract_address = address for contract metadata

​
Commonly-used Fields

  • tx_hash: Parent transaction identifier
  • event_index: Position of the event within the transaction
  • contract_address: Contract that emitted the event
  • topic_0: Event signature hash (keccak256 of event declaration)
  • data: Hex-encoded non-indexed parameters
  • topics: Array of all indexed parameters

​
Sample queries

-- TRC-20 Transfer events in the last 24 hours
SELECT
    block_timestamp,
    tx_hash,
    contract_address,
    topic_1 AS from_address_raw,
    topic_2 AS to_address_raw,
    data AS amount_raw
FROM tron.core.fact_event_logs
WHERE block_timestamp >= CURRENT_DATE - 1
    AND topic_0 = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'  -- Transfer(address,address,uint256)
ORDER BY block_timestamp DESC
LIMIT 100;

-- Most active contracts by event count
SELECT
    contract_address,
    COUNT(*) AS event_count,
    COUNT(DISTINCT topic_0) AS unique_event_types,
    COUNT(DISTINCT tx_hash) AS unique_transactions
FROM tron.core.fact_event_logs
WHERE block_timestamp >= CURRENT_DATE - 1
GROUP BY 1
ORDER BY 2 DESC
LIMIT 50;

-- Event patterns within a specific transaction
SELECT
    event_index,
    contract_address,
    topic_0,
    SUBSTRING(data, 1, 10) AS data_preview
FROM tron.core.fact_event_logs
WHERE tx_hash = '0xabc...'
ORDER BY event_index;

​
Columns

Column NameData TypeDescription
BLOCK_NUMBERNUMBERSequential counter representing the position of a block in the Tron blockchain since genesis (block 0). Key Facts: Immutable once finalized Primary ordering mechanism for blockchain data Increments by 1 for each new block Encoded in the first bytes of blockhash Usage in Queries: Important: Many early Tron blocks are empty (zero transactions). Expect blocknumber gaps in transaction-based tables.
BLOCK_HASHTEXTThe unique hash of the block header. Key Facts: Contains the block number encoded in its first bytes Used for chain reorganization detection Example: ‘0x00000000033fc3d68297d9c3bfab0a01c57a56a61a82f270ba7f9e4400000000’
BLOCK_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the block was produced by the super representative (SR). Format: TIMESTAMP_NTZ (no timezone) Precision: Second-level accuracy Best Practices: Note: Tron produces blocks every 3 seconds via DPoS consensus.
TX_HASHTEXTUnique identifier for the transaction. Format: 0x + 64 hexadecimal characters Usage: Primary key for transaction lookups Join key for event logs, internal transactions, and token transfers Immutable once confirmed Example: ‘0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060’
TX_POSITIONNUMBERZero-indexed position of the transaction within its block. Example: 5
EVENT_INDEXNUMBERZero-based sequential position of the event log within the transaction’s execution. Key Facts: Starts at 0 for first event Increments across all contracts in transaction Preserves execution order Used with tx_hash as a composite key for unique event identification
CONTRACT_ADDRESSTEXTSmart contract address that emitted the event or received the transaction, in 0x-prefixed hex format. Key Points: Always the immediate event emitter for logs May differ from transaction to_address Lowercase normalized Never NULL for valid events
DATATEXTHex-encoded non-indexed event parameters. Contains the ABI-encoded values of parameters not marked as indexed in the event declaration. Example: ‘0x00000000000000000000000000000000000000000000000000000000000f4240’
TOPICSVARIANTArray containing all indexed parameters of the event, with topic_0 being the event signature hash. Example: [‘0xddf252ad…’, ‘0x00000000…sender’, ‘0x00000000…receiver’]
TOPIC_0TEXTEvent signature hash — the keccak256 hash of the event declaration (e.g., Transfer(address,address,uint256)). Used to identify event types. Example: ‘0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef’
TOPIC_1TEXTFirst indexed parameter of the event (if exists). For Transfer events, this is typically the sender address.
TOPIC_2TEXTSecond indexed parameter of the event (if exists). For Transfer events, this is typically the receiver address.
TOPIC_3TEXTThird indexed parameter of the event (if exists).
EVENT_REMOVEDBOOLEANBoolean flag indicating if the event was removed due to a chain reorganization. TRUE means this event is no longer part of the canonical chain.
ORIGIN_FROM_ADDRESSTEXTThe address that initiated the originating transaction, in 0x-prefixed hex format. Useful when viewing events or internal transactions to trace back to the original caller.
ORIGIN_TO_ADDRESSTEXTThe destination address of the originating transaction. For contract interactions, this is the contract that was directly called (not necessarily the contract that emitted the event).
ORIGIN_FUNCTION_SIGNATURETEXTFunction signature (first 4 bytes) of the called method in the originating transaction. Format: 0x + 8 hex characters Common Signatures: 0xa9059cbb: transfer(address,uint256) 0x095ea7b3: approve(address,uint256) 0x23b872dd: transferFrom(address,address,uint256) Note: NULL for simple TRX transfers or non-contract calls.
TX_SUCCEEDEDBOOLEANBoolean indicator of transaction success. Values: TRUE: Transaction executed successfully FALSE: Transaction failed/reverted
FACT_EVENT_LOGS_IDTEXTPrimary key — unique identifier for each row ensuring data integrity. Format: VARCHAR containing composite key generated using MD5 hash of the relevant columns. Usage: Deduplication in incremental loads Join operations for data quality checks Troubleshooting specific records
INSERTED_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the record was first added to the Flipside database. Format: TIMESTAMP_NTZ Use Cases: Data freshness monitoring Incremental processing markers Debugging data pipeline issues
MODIFIED_TIMESTAMPTIMESTAMP_NTZUTC timestamp of the most recent update to this record. Format: TIMESTAMP_NTZ Use Cases: Tracking data corrections and reprocessing Monitoring incremental model updates Data quality audits