Skip to main content
Schema: flow.core Table: ez_transaction_actors Type: Base Table

​
Description

This curated table extracts all addresses involved in the events of each transaction on the Flow blockchain, generating an array of distinct actors for every transaction. Actors include authorizers, payers, proposers, and any other addresses referenced in transaction events. The table provides a normalized, analytics-ready view of transaction participants, supporting entity-level analysis and wallet attribution.

​
Key Use Cases

  • Identifying all participants in a transaction for compliance and risk analysis
  • Supporting wallet attribution, entity mapping, and participant segmentation
  • Enabling analytics on transaction complexity, multi-sig usage, and collaborative workflows
  • Building dashboards for protocol, dApp, or user-level activity

​
Important Relationships

  • Derived from core.fact_transactions and core.fact_events by extracting and aggregating participant addresses
  • Can be joined to core.dim_labels via actors for entity enrichment
  • Used by curated models in DeFi, NFT, and rewards domains to provide participant context

​
Commonly-used Fields

  • tx_id: Unique identifier for the transaction
  • actors: Array of all addresses involved in the transaction (authorizers, payers, proposers, event participants)
  • block_timestamp: Used for time-series and participant trend analysis

​
Columns

Column NameData TypeDescription
BLOCK_HEIGHTNUMBERThe block number, corresponds with height.
BLOCK_TIMESTAMPTIMESTAMP_NTZThe timestamp (in UTC) when the block or transaction was recorded on the Flow blockchain. Data type: TIMESTAMP_NTZ. This field is essential for time-series analysis, ordering events, and joining with other tables by time. For example, a block with block_height 100,000 may have a block_timestamp of ‘2023-01-01 12:00:00’. Used for analytics on network activity, transaction throughput, and historical state reconstruction.
TX_IDTEXTThe unique identifier (hash) for a transaction on the Flow blockchain. Data type: STRING. Each transaction is assigned a cryptographic hash that ensures its uniqueness and immutability. Used for joining transaction data across tables, tracing transaction execution, and verifying transaction integrity. Example: ‘e3f1c2d4…’. Essential for transaction-level analytics, debugging, and cross-referencing with block and event data.
ACTORSARRAYAn array of unique addresses involved in the events of a transaction, tagging them as actors in the transaction.
PAYERTEXT
PROPOSERTEXT
AUTHORIZERSARRAY
TX_SUCCEEDEDBOOLEANTransaction status, if it succeeded or failed.
EZ_TRANSACTION_ACTORS_IDTEXTpk_id is a surrogate primary key, uniquely generated for each row in the table. Data type: STRING or INTEGER (implementation-specific). This field ensures every record is uniquely identifiable, even if the source data lacks a natural primary key. Used for efficient joins, deduplication, and as a reference in downstream models. Example: an auto-incremented integer or a UUID string. Essential for maintaining data integrity and supporting dbt tests for uniqueness.
INSERTED_TIMESTAMPTIMESTAMP_NTZThe UTC timestamp when the record was first created and inserted into this table. Data type: TIMESTAMP_NTZ. Used for ETL auditing, tracking data freshness, and identifying when data was loaded or updated in the analytics pipeline. Example: ‘2023-01-01 12:00:00’. This field is critical for monitoring data latency, troubleshooting ETL issues, and supporting recency tests in dbt.
MODIFIED_TIMESTAMPTIMESTAMP_NTZThe UTC timestamp when this record was last updated or modified by an internal ETL or dbt process. Data type: TIMESTAMP_NTZ. Used for change tracking, ETL auditing, and identifying the most recent update to a record. Example: ‘2023-01-02 15:30:00’. This field is important for troubleshooting data issues, monitoring pipeline health, and supporting recency or freshness tests in dbt.