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

## 1. Overview

Weekly active addresses measures the number of unique addresses that interact with the Flow blockchain ecosystem over rolling 7-day periods. This metric captures user engagement across Flow's dual execution environments: Flow EVM (EVM-compatible layer) and Flow (native Flow environment). The calculation uses HyperLogLog algorithms for efficient deduplication across the rolling time windows and counts all transaction participants including senders, fee payers, proposers, and authorizers.

## 2. Data sources

- **Flow EVM transaction records**: Standard EVM-compatible transaction data containing sender addresses, transaction hashes, block timestamps, and transaction metadata
- **Flow Cadence transaction records**: Native Flow transaction data including payer addresses, proposal key addresses, gas limits, fees, and transaction identifiers  
- **Flow collections metadata**: Transaction authorization data containing arrays of authorizer addresses for each transaction
- **Flow blockchain metadata**: Chain identifiers, block numbers, block heights, and timestamp information across both execution environments

## 3. Step-by-step calculation

### Component A: Flow EVM user extraction
- **Purpose**: Identifies active addresses from EVM-compatible transactions on Flow
- **Logic**: Extracts sender addresses from Flow EVM transaction records. Each transaction sender is considered an active user for that day. Records are filtered to include only transactions with valid sender addresses and are grouped by day and address to ensure each address is counted only once per day.
- **Key fields**: `from_address` as the user address, `block_timestamp` for daily grouping, `transaction_hash` for transaction identification

### Component B: Flow user extraction  
- **Purpose**: Identifies active addresses from native Flow Cadence transactions across multiple participant roles
- **Logic**: Extracts three types of transaction participants from Flow Cadence data. First, payers who pay transaction fees are identified from the `payer` field. Second, proposers are identified from `proposal_key_address` fields. Third, authorizers are extracted by unnesting authorizer arrays from collections data and cross-joining with transaction records. All three participant types are considered active users.
- **Key fields**: `payer` addresses, `proposal_key_address` fields, `authorizers` arrays from collections, `block_timestamp` for temporal grouping

### Component C: Daily active user aggregation
- **Purpose**: Combines and deduplicates users across both Flow environments to create daily active user counts
- **Logic**: Unions Flow EVM and Flow users into a single dataset. Performs deduplication by truncating timestamps to day level and selecting distinct combinations of date and user address. This ensures each unique address is counted only once per day regardless of how many transactions they participated in or which roles they played.
- **Key fields**: `user_address` for deduplication, `timestamp` truncated to day granularity, environment identifiers for tracking data sources

### Component D: HyperLogLog sketch creation
- **Purpose**: Converts daily user lists into HyperLogLog sketches for efficient weekly aggregation
- **Logic**: Groups daily active users by timestamp, chain, user type, and product dimensions. Initializes HyperLogLog sketches using the `hll_count.init` function with precision parameter 15. This creates compact probabilistic data structures that enable efficient unique counting across time windows without storing individual user addresses.
- **Key fields**: HyperLogLog sketches (`hll`) containing user address information, grouping dimensions for later aggregation

### Component E: Rolling window construction
- **Purpose**: Creates 7-day rolling windows using a datespine approach to ensure complete time coverage
- **Logic**: Generates a complete date spine from the earliest data date to yesterday. For each date in the spine, creates join relationships with the previous 6 days to form 7-day rolling windows. This approach ensures that weeks with missing data days are still properly calculated and prevents gaps in the time series.
- **Key fields**: `timestamp` for the current day, `joinday` for each day in the 7-day lookback window

### Component F: Weekly aggregation using HyperLogLog
- **Purpose**: Aggregates unique users across 7-day rolling windows using HyperLogLog merging
- **Logic**: Joins the rolling window structure with daily HyperLogLog sketches. For each 7-day window, merges HyperLogLog sketches using `hll_count.merge_partial` to combine unique user counts across the week. Extracts final counts using `hll_count.extract` to get the estimated number of unique users in each 7-day period.
- **Key fields**: Merged HyperLogLog sketches, extracted weekly unique user counts (`user_wau`)

### Component G: Dimensional breakdowns
- **Purpose**: Calculates weekly active users across different analytical dimensions
- **Logic**: Creates separate aggregations for four analytical dimensions. Project-level aggregation sums across all chains and products. Chain-level aggregation groups by individual chains within Flow. User-type aggregation separates different participant roles. Product-level aggregation distinguishes between Flow EVM and Flow environments. Each dimension uses HyperLogLog merging to maintain unique counting properties.
- **Key fields**: `dimensions` field indicating aggregation level, dimension-specific identifiers like `chain_id` and `product_id`

### Final aggregation
- **Combining components**: The dimensional breakdowns are combined using union operations to create a comprehensive dataset containing weekly active users across all analytical dimensions
- **Metric transformation**: The `user_wau` field is renamed to `active_addresses_weekly` to reflect the standard naming convention for blockchain address activity metrics
- **Time boundaries**: Weekly calculations use 7-day rolling windows ending on each date, ensuring consistent temporal aggregation across the time series
- **Final calculation**: The metric represents the estimated number of unique addresses that interacted with Flow blockchain (either Flow EVM or Flow) during each 7-day rolling period, calculated using HyperLogLog probabilistic counting for computational efficiency

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

Unique active addresses over a rolling 7-day window.

FlowFLOW

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown