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

What

This table contains decoded event logs for Tron smart contracts, transforming raw hex data into human-readable event signatures and parsed arguments. Only includes events from contracts where decoding information is available.

Key Use Cases

  • Analyzing token transfers, approvals, and other decoded events without manual hex parsing
  • Filtering by human-readable event signatures (e.g., Transfer(address,address,uint256))
  • Querying decoded arguments directly for protocol-specific analysis
  • Monitoring DeFi protocol interactions (swaps, liquidity events, staking)

Important Relationships

  • Join with fact_event_logs: Use tx_hash and event_index for raw 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

  • event_signature: Human-readable event declaration (e.g., Transfer(address,address,uint256))
  • event_hash: Keccak256 hash of the event signature (same as topic_0)
  • args: Decoded event arguments as structured data
  • contract_address: Contract that emitted the event
  • tx_hash: Parent transaction

Sample queries

-- TRC-20 Transfer events with decoded arguments
SELECT
    block_timestamp,
    tx_hash,
    contract_address,
    args
FROM tron.core.fact_decoded_event_logs
WHERE block_timestamp >= CURRENT_DATE - 1
    AND event_signature = 'Transfer(address,address,uint256)'
ORDER BY block_timestamp DESC
LIMIT 100;

-- Most common decoded event types
SELECT
    event_signature,
    COUNT(*) AS event_count,
    COUNT(DISTINCT contract_address) AS unique_contracts
FROM tron.core.fact_decoded_event_logs
WHERE block_timestamp >= CURRENT_DATE - 7
GROUP BY 1
ORDER BY 2 DESC
LIMIT 50;

-- Events for a specific contract
SELECT
    block_timestamp,
    event_signature,
    args,
    tx_hash
FROM tron.core.fact_decoded_event_logs
WHERE contract_address = LOWER('0x...')
    AND block_timestamp >= CURRENT_DATE - 7
ORDER BY block_timestamp DESC;

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
EVENT_HASHTEXTThe keccak256 hash of the event signature. Equivalent to topic0 in factevent_logs. Example: ‘0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef’
EVENT_SIGNATURETEXTThe human-readable signature of the decoded event, including parameter types. Example: ‘Transfer(address,address,uint256)‘
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).
ARGSTEXTThe decoded arguments of the event as structured data, with named parameters matching the event signature. Example: {"from": "0x...", "to": "0x...", "value": "1000000"}
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_DECODED_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