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 (weekly) Methodology

## 1. Overview

Weekly transaction participants measures the number of unique addresses that actively participate in Flow blockchain transactions over rolling 7-day periods. This metric captures comprehensive on-chain activity across Flow's dual execution environments (Flow EVM and Flow), providing insights into user engagement and ecosystem growth. The calculation uses HyperLogLog algorithms for efficient approximate distinct counting across multiple dimensional breakdowns.

## 2. Data sources

The metric draws from multiple Flow blockchain data sources:
- **Flow transaction records**: Native Cadence transaction data including payer addresses, proposal key addresses, gas limits, and fee amounts
- **Flow EVM transaction records**: Ethereum-compatible transaction data with sender addresses and transaction metadata  
- **Flow collections data**: Nested transaction collections containing authorizer address arrays for comprehensive signer tracking
- **Flow events data**: Parsed `FungibleToken.Deposited` and `NonFungibleToken.Deposited` events capturing token and NFT recipients
- **Flow contract metadata**: Contract addresses and names for filtering relevant token/NFT activities

## 3. Step-by-step calculation

### Component A: Flow EVM participant extraction
- **Purpose**: Identifies active addresses from Ethereum-compatible transactions on Flow
- **Logic**: Extracts sender addresses from Flow EVM transaction records. Each transaction sender represents an active participant who initiated EVM-compatible activity. Addresses are normalized to string format and associated with daily timestamps, chain identifier, and user type classification.
- **Key fields**: `from_address` as the participant address, `block_timestamp` for daily aggregation boundaries, transaction hash for deduplication context

### Component B: Flow participant extraction  
- **Purpose**: Captures comprehensive participation types specific to Flow's native Cadence environment
- **Logic**: Identifies five distinct participant types from different data sources. Payers are extracted from transaction fee records, proposers from proposal key addresses, authorizers from unnested collections data, token receivers from non-FLOW `FungibleToken.Deposited` events (excluding FlowToken contract), and NFT receivers from `NonFungibleToken.Deposited` events. Each type represents different forms of active blockchain participation requiring specific on-chain setup or authorization.
- **Key fields**: `payer`, `proposal_key_address`, `authorizers` arrays, `to` addresses from event payloads, contract addresses for filtering relevant activities

### Component C: Daily participant aggregation
- **Purpose**: Consolidates all participant types into daily unique address counts
- **Logic**: Combines Flow EVM and Flow participants, deduplicating addresses within each day, user type, chain, and product combination. Applies chain availability filters to ensure data completeness. Timestamps are truncated to day boundaries for consistent aggregation periods.
- **Key fields**: `transaction_participants_daily` containing unique addresses, `timestamp` truncated to day level, dimensional attributes for later breakdowns

### Component D: HyperLogLog initialization
- **Purpose**: Converts daily distinct counts to probabilistic data structures for efficient weekly aggregation
- **Logic**: Initializes HyperLogLog sketches for each daily participant set using precision parameter 15, providing approximate distinct counting with controlled memory usage. Groups by timestamp, chain, user type, and product dimensions to maintain granular tracking while enabling efficient merging operations.
- **Key fields**: `hll` sketches containing compressed distinct address representations, dimensional grouping fields preserved for downstream aggregation

### Component E: Rolling window construction
- **Purpose**: Creates 7-day rolling windows for weekly participant calculation
- **Logic**: Generates complete datespine covering the full time range to avoid gaps in time series data. For each day, creates joins to the previous 6 days using timestamp arithmetic, forming 7-day windows. Uses inner joins with daily HLL data to populate windows with actual participant sketches, applying incremental filtering for efficient processing.
- **Key fields**: `timestamp` as window end date, `joinday` for window member days, HLL sketches carried forward from daily aggregation

### Component F: Dimensional breakdown calculation
- **Purpose**: Calculates weekly metrics across different analytical dimensions
- **Logic**: Creates four separate dimensional views by grouping and merging HLL sketches. Project-level breakdown merges all dimensions, chain-level maintains chain separation, user type breakdown preserves user classifications, and product-level breakdown separates Flow EVM and Flow metrics. Uses HLL merge operations to combine sketches across the appropriate dimensional boundaries while nullifying unused dimension fields.
- **Key fields**: `dimensions` indicating breakdown type, preserved dimensional fields, merged HLL sketches for final extraction

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into single result set with consistent schema structure
- **HLL extraction**: Extract final approximate distinct counts from merged HLL sketches using HyperLogLog count extraction functions
- **Time aggregation**: Apply 7-day rolling window boundaries with day-level granularity for consistent weekly measurement periods
- **Final calculation**: Weekly transaction participants equals the approximate distinct count of addresses that participated in any Flow blockchain activity (transactions, token transfers, NFT transfers, or contract interactions) during the 7-day rolling window, calculated separately for each dimensional breakdown

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

Unique addresses participating in transactions over a rolling 7-day window.

FlowFLOW

Transaction participants (weekly)

Transaction participants (weekly)

Competitive landscape

Chain breakdown