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

Celo is a smart contract platform for decentralized applications (a blockchain). Celo was founded by Rene Reinsberg and Marek Olszewski and launched in 2020.

CELO holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue). Celo's investors include a16z, Greenfield, Electric Capital, etc.

governance

github

twitter

discord

etherscan

website

Blockchains (L2)

Celo

# Celo Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Celo L1 (legacy) measures the number of unique addresses that initiated at least one transaction on the Celo L1 (legacy) blockchain within any rolling 30-day period. This metric provides insights into user engagement and adoption trends for the Celo L1 (legacy) ecosystem, including both Celo L1 (legacy) L1 and Celo L1 (legacy) L2 (post-March 2025). The calculation uses HyperLogLog algorithms for efficient distinct counting across overlapping time windows and provides breakdowns by project, chain, user type, and product dimensions.

## 2. Data sources

- **Celo L1 (legacy) blockchain transaction records**: Complete transaction history from the Celo L1 (legacy) blockchain including transaction metadata, timestamps, and participant addresses
- **Transaction timestamp data**: Block timestamps for ordering and time-based aggregation of user activity
- **Transaction sender addresses**: The `from_address` field identifying the initiator of each transaction, used as the primary user identifier
- **Chain transition metadata**: Logic to distinguish between Celo L1 (legacy) L1 and Celo L1 (legacy) L2 transactions based on the March 26, 2025 transition date

## 3. Step-by-step calculation

### Component A: User transaction extraction
- **Purpose**: Identifies all transaction senders from Celo L1 (legacy) blockchain data and classifies them by product and timeframe
- **Logic**: Extracts transaction data from Celo L1 (legacy) blockchain records, capturing the `from_address` as the user identifier along with `block_timestamp` and `transaction_hash`. Applies business logic to classify transactions before March 26, 2025 as Celo L1 (legacy) L1 (`product_id` = 'Celo L1 (legacy)', `market_sector_id` = 'blockchains_l1') and transactions from March 26, 2025 onward as Celo L1 (legacy) L2 (`product_id` = 'Celo L1 (legacy) L2', `market_sector_id` = 'blockchains_l2'). All users are classified with `user_type` = 'Transaction sender'
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` (from `from_address`) for user identification, `chain` set to 'Celo L1 (legacy)', `product_id` for L1/L2 distinction, `user_type` for user classification

### Component B: Daily active user calculation
- **Purpose**: Aggregates unique users on a daily basis while preserving dimensional metadata for downstream analysis
- **Logic**: Groups transaction data by day using timestamp truncation to day granularity. Identifies distinct `user_address` values for each day, creating one record per unique user-day combination. Preserves dimensional attributes including `chain`, `user_type`, and `product_id` for later aggregation. Uses incremental processing to handle late-arriving data with configurable lookback periods
- **Key fields**: `timestamp` truncated to day, `timestamp_grain` set to 'day', `user_dau` containing the unique user address, dimensional fields for grouping

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user sets into efficient HyperLogLog sketches for scalable distinct counting across time windows
- **Logic**: Takes the daily active user data and creates HyperLogLog sketches using `hll_count.init()` with precision parameter 15. Groups by timestamp, timestamp grain, chain, user type, and product ID to create HLL sketches for each dimensional combination. This enables efficient merging and distinct counting across overlapping time periods
- **Key fields**: `hll` containing the HyperLogLog sketch, grouping dimensions for maintaining separate sketches per category

### Component D: Rolling window creation
- **Purpose**: Generates complete 30-day rolling windows to ensure comprehensive MAU coverage without gaps
- **Logic**: Creates a datespine covering the full time range of available data using `generate_timestamp_array()` with daily intervals. For each date in the datespine, generates a 30-day lookback window by creating join days for the current date plus the previous 29 days. This approach ensures that every day has a complete 30-day window for MAU calculation, even if some days have no user activity
- **Key fields**: `timestamp` for the target date, `joinday` for each day in the 30-day window used for joining with daily HLL data

### Component E: Dimensional MAU aggregation
- **Purpose**: Calculates MAU across four different dimensional breakdowns for comprehensive analysis
- **Logic**: Merges HyperLogLog sketches across the 30-day windows for each dimensional breakdown: project-level (all dimensions nullified), chain-level (grouped by `chain_id`), user type-level (grouped by `user_type`), and product-level (grouped by `product_id`). Uses `hll_count.merge_partial()` to combine HLL sketches and `hll_count.extract()` to get the final distinct count. Each breakdown nullifies irrelevant dimensions while preserving the target dimension for grouping
- **Key fields**: `user_mau` containing the distinct user count, `dimensions` indicating the breakdown type, dimensional fields with appropriate values or nulls

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single result set using `UNION ALL` operations, creating a comprehensive view with multiple levels of granularity
- **Currency conversion**: Not applicable - this is a count-based metric
- **Time aggregation**: Uses rolling 30-day windows where each day's MAU represents unique users from that day plus the previous 29 days. Incremental processing ensures efficient updates with configurable lookback periods for handling late data
- **Final calculation**: Applies the `finalize_metric_user_mau` macro to standardize the output schema, fill missing time periods with zeros, and ensure consistent formatting across all Celo L1 (legacy) MAU metrics. The final MAU value represents the distinct count of user addresses that initiated at least one transaction within any 30-day rolling window

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

Unique revenue-generating users over a rolling 30-day window.

CeloCELO

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown