Validators process transactions and receive fees from users (supply-side fees).

Flow is a smart contract platform for decentralized applications (a blockchain). Flow was founded by Roham Gharegozlou, Dieter Shirley and Mikhael Naayem and launched in 2019.

FLOW holders own and govern the protocol. They currently don’t take a cut of the total transaction fees paid by users (revenue). Flow’s investors include a16z, Coatue, Coinfund, Fabric Ventures, etc.

governance

github

twitter

discord

website

Blockchains (L1)

Flow

# Flow Transaction participants (daily) Methodology

## 1. Overview

Transaction participants daily measures the number of unique addresses that actively participated in transactions on the Flow blockchain each day. This metric captures comprehensive user activity across Flow's dual execution environments: Flow EVM (Ethereum-compatible) and Flow (native Flow smart contracts). The metric identifies participants through multiple interaction types including transaction signing, fee payment, token transfers, and NFT operations, providing a holistic view of daily active addresses on the Flow ecosystem.

## 2. Data sources

The calculation draws from several Flow blockchain data sources:
- **Flow blockchain transaction records**: Core transaction metadata including payers, proposal key addresses, gas limits, and fee amounts
- **Flow EVM blockchain transaction records**: Ethereum-compatible transaction data with sender addresses  
- **Flow blockchain event logs**: Parsed `FungibleToken` and `NonFungibleToken` events, specifically `Deposited` events that indicate token and NFT transfers to recipient addresses
- **Flow collections metadata**: Transaction collections data containing nested arrays of transaction authorizers

## 3. Step-by-step calculation

### Component A: Flow EVM participants identification
- **Purpose**: Identifies unique daily transaction participants from Flow's Ethereum-compatible execution environment
- **Logic**: Extracts transaction sender addresses from Flow EVM blockchain transaction records. Each transaction sender is classified as a 'user' participant type under the 'Flow EVM' product. Transactions are deduplicated by day to count each address only once per day regardless of transaction volume
- **Key fields**: `block_timestamp` for daily grouping, `from_address` as the participant address, `transaction_hash` for transaction identification

### Component B: Flow participants identification  
- **Purpose**: Identifies comprehensive participant types from Flow's native smart contract execution environment
- **Logic**: Extracts five distinct participant categories: 1) Payers who pay transaction fees, 2) Proposers who provide proposal key addresses, 3) Authorizers extracted by unnesting nested authorizer arrays from collections metadata, 4) Token receivers who receive non-FLOW fungible tokens (requires vault setup, excludes FlowToken contract `1654653399040a61`), 5) NFT receivers who receive NFTs through `NonFungibleToken` `Deposited` events (requires collection setup, limited to contract `1d7e57aa55817448`). Token and NFT receiver addresses are extracted by parsing JSON event payloads for the `to` field
- **Key fields**: `block_timestamp` for daily grouping, participant addresses from various sources (`payer`, `proposal_key_address`, `authorizer`, extracted `to` addresses), `user_type` to categorize participant role

### Component C: Participant combination and deduplication
- **Purpose**: Combines Flow EVM and Flow participants into a unified dataset
- **Logic**: Unions Flow EVM users and Flow participants, maintaining distinct user types and product classifications. Deduplicates participants by day, chain, user type, and address to ensure each unique address-role combination is counted once per day. Standardizes schema with consistent market sector ('blockchains_l1') and business segment ('blockchain') classifications
- **Key fields**: `timestamp` truncated to day level, `user_type` for participant categorization, `product_id` for execution environment classification, `transaction_participants_daily` containing the participant address

### Component D: HyperLogLog aggregation preparation
- **Purpose**: Prepares participant data for efficient unique counting using HyperLogLog algorithm
- **Logic**: Initializes HyperLogLog counters for each combination of day, timestamp grain, chain, user type, and product. Uses HLL precision of 15 bits for accurate unique counting while enabling efficient aggregation across dimensions
- **Key fields**: `hll` containing HyperLogLog counter state for unique participant counting

### Component E: Multi-dimensional breakdowns
- **Purpose**: Creates aggregated participant counts across different analytical dimensions
- **Logic**: Generates four dimensional views: 1) Project-level totals aggregating all participants regardless of chain, user type, or product, 2) Chain-level breakdowns counting participants by blockchain, 3) User type breakdowns counting participants by interaction role, 4) Product-level breakdowns counting participants by execution environment (Flow EVM vs Flow). Uses HyperLogLog merge operations to combine counters while preserving unique counting accuracy
- **Key fields**: `dimensions` indicating aggregation level, dimension-specific identifiers (`chain_id`, `user_type`, `product_id`), `transaction_participants_daily` containing final unique participant counts

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single result set with standardized schema and null values for non-applicable dimension fields
- **Currency conversion**: Not applicable as this metric counts participants rather than monetary values
- **Time aggregation**: Uses daily boundaries with timestamp truncation to day level, ensuring participants are counted once per day regardless of transaction frequency
- **Final calculation**: Extracts unique participant counts from merged HyperLogLog counters, applies standardized metric finalization including zero-filling for missing days, and applies chain availability filters to ensure data quality and consistency

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Unique addresses participating in transactions over a fixed 24-hour window.

FlowFLOW

Transaction participants (daily)

Transaction participants (daily)

Competitive landscape

Chain breakdown