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

## 1. Overview

Flow monthly active addresses measures the number of unique addresses that have been active on the Flow blockchain within a rolling 30-day window. This metric captures user engagement across both Flow execution environments: Flow EVM (Ethereum-compatible) and Flow (native Flow). The calculation aggregates different types of user activity including transaction initiation, fee payment, transaction proposal, and transaction authorization. For Flow, "active addresses" and "monthly active users" are equivalent concepts, as each unique address represents a distinct user on the blockchain.

## 2. Data sources

The calculation draws from three primary blockchain data sources:

- **Flow Cadence transactions**: Native Flow transaction records containing payer addresses, proposal key addresses, gas limits, and fee amounts
- **Flow EVM transactions**: Ethereum-compatible transaction data with sender addresses and transaction metadata  
- **Flow collections data**: Nested transaction collections containing authorizer address arrays for each transaction
- **Timestamp data**: Block timestamps for all transactions to enable time-based aggregation

## 3. Step-by-step calculation

### Component A: Flow EVM user identification
- **Purpose**: Extract unique user addresses from Ethereum-compatible Flow transactions
- **Logic**: Process Flow EVM transaction records and extract the `from_address` field as the user identifier. Cast timestamps to daily boundaries and assign metadata including chain identifier as 'Flow EVM', market sector as 'blockchains_l1', business segment as 'blockchain', and user type as 'user'. Filter out any records with null sender addresses.
- **Key fields**: `block_timestamp` for temporal aggregation, `transaction_hash` for transaction identification, `from_address` as the unique user identifier

### Component B: Flow user identification  
- **Purpose**: Extract unique user addresses from native Flow transactions across three distinct roles
- **Logic**: Identify users through three separate roles within Flow Cadence transactions. First, extract payer addresses who pay transaction fees using the `payer` field. Second, extract proposal key addresses who propose transactions using the `proposal_key_address` field. Third, extract authorizer addresses by unnesting the nested `authorizers` array from the collections data structure. Each role represents a distinct form of user activity. Combine all three user types using union operations while maintaining separate role identification. Assign chain identifier as 'flow' and the same metadata structure as Flow EVM users.
- **Key fields**: `payer` for fee-paying users, `proposal_key_address` for transaction proposers, `authorizer` array for transaction authorizers, `block_timestamp` for time-based grouping

### Component C: Daily active user aggregation
- **Purpose**: Combine both execution environments and aggregate to daily unique users
- **Logic**: Union the Flow EVM and Flow user datasets to create a comprehensive view of all Flow ecosystem activity. Truncate block timestamps to day boundaries and use distinct operations to ensure each address is counted only once per day, regardless of how many transactions they performed or roles they played. This creates a daily active user (DAU) dataset that serves as the foundation for monthly calculations.
- **Key fields**: `timestamp` truncated to day granularity, `user_address` as the unique identifier, dimensional attributes like `chain`, `user_type`, `product_id`

### Component D: Monthly active user calculation with HyperLogLog
- **Purpose**: Calculate rolling 30-day monthly active users using probabilistic counting
- **Logic**: Initialize HyperLogLog sketches for each daily user dataset to enable efficient approximate distinct counting. Create a complete datespine covering all days from the earliest data to present, then generate rolling 30-day windows for each date using timestamp arrays. For each day, collect HLL sketches from the current day and the previous 29 days to form a 30-day window. Merge the HLL sketches within each window and extract the estimated distinct count. This approach avoids double-counting users who are active on multiple days within the same month while maintaining computational efficiency.
- **Key fields**: HLL sketches initialized from `user_dau`, rolling window boundaries defined by datespine joins, merged HLL counts extracted as `user_mau`

### Component E: Dimensional breakdowns
- **Purpose**: Create multiple analytical perspectives of the monthly active user data  
- **Logic**: Generate four distinct dimensional views of the MAU data. Create project-level aggregation by summing across all chains and products. Create chain-level breakdown separating Flow EVM and Flow Cadence activity. Create user-type breakdown distinguishing different user roles. Create product-level breakdown for granular analysis. Each breakdown maintains the same temporal structure while aggregating HLL sketches appropriately to preserve distinct count accuracy.
- **Key fields**: `dimensions` field indicating breakdown type, `chain_id` for chain-specific views, `user_type` for role-based analysis, `product_id` for product-specific metrics

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single comprehensive dataset containing multiple analytical perspectives of the same underlying MAU calculation
- **Schema standardization**: Apply the finalize metric macro to standardize field names, data types, and ensure consistent schema structure across all dimensional views
- **Missing data handling**: Fill any missing time periods with zero values to maintain complete time series continuity for downstream analytics
- **Final calculation**: Rename the `user_mau` field to `active_addresses_monthly` to align with the metric naming convention, while filtering to include only chain-level and project-level dimensional views as specified by the dimensions filter

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

Unique addresses active over a rolling 30-day window.

FlowFLOW

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown