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

## 1. Overview

Monthly active addresses measures the number of unique wallet addresses that sent at least one transaction on the Celo L1 (legacy) blockchain within a rolling 30-day period. This metric provides insight into user adoption and engagement with the Celo L1 (legacy) ecosystem. The calculation treats transaction senders as active addresses and uses approximate counting methods for computational efficiency. The methodology accounts for Celo L1 (legacy)'s transition to L2, tracking both Celo L1 (legacy) L1 and Celo L1 (legacy) L2 activity as separate products while providing consolidated metrics.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Celo L1 (legacy) blockchain transactions**: Complete transaction records from the Celo L1 (legacy) blockchain containing sender addresses, transaction hashes, and block timestamps
- **Transaction metadata**: Block timestamps used for temporal aggregation and time-based filtering
- **Address data**: Transaction sender addresses (`from_address`) that represent active users on the network

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Extract and classify unique transaction senders as active addresses
- **Logic**: The system processes all Celo L1 (legacy) blockchain transactions and extracts the sender address (`from_address`) from each transaction. Each sender address is treated as a unique user. Transactions are classified by time period using the `block_timestamp` field - transactions before March 26, 2025 are classified as Celo L1 (legacy) L1 activity with product ID 'Celo L1 (legacy)', while transactions from that date forward are classified as Celo L1 (legacy) L2 activity with product ID 'Celo L1 (legacy) L2'. Both types are tagged with appropriate market sectors ('blockchains_l1' vs 'blockchains_l2') and business segment 'blockchain'. All senders are categorized as 'Transaction sender' user type.
- **Key fields**: `from_address` (sender address), `block_timestamp` (transaction time), `transaction_hash` (unique identifier), `chain` (always 'Celo L1 (legacy)')

### Component B: Daily active user calculation
- **Purpose**: Aggregate unique addresses into daily distinct counts
- **Logic**: Transaction data is grouped by day using timestamp truncation to day boundaries. For each day, the system identifies all distinct sender addresses that sent at least one transaction. This creates a daily active users dataset where each record represents a unique address that was active on a specific day. The data includes chain information, user type classification, and product ID based on the L1/L2 classification from the previous step.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` ('day'), `user_address` (distinct sender per day), `chain`, `user_type`, `product_id`

### Component C: HyperLogLog approximation setup
- **Purpose**: Convert daily distinct users into efficient approximate counting structures
- **Logic**: The daily active users are transformed into HyperLogLog sketches with precision level 15. This probabilistic data structure allows for efficient approximate distinct counting when aggregating across multiple time periods. Each day's distinct users are initialized as a single HyperLogLog sketch, grouped by timestamp, chain, user type, and product ID. This approach enables scalable computation of monthly active users without storing or processing complete sets of addresses.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window creation
- **Purpose**: Create 30-day rolling windows for monthly active user calculation
- **Logic**: A datespine is generated covering all days from the earliest transaction date to yesterday. For each day in the datespine, the system creates associations with the previous 29 days (creating a 30-day window). This results in a join table where each target date is associated with all constituent dates in its 30-day window. The daily HyperLogLog sketches are then joined with this window structure, creating a dataset where each day has access to HyperLogLog data from all days in its 30-day window.
- **Key fields**: `timestamp` (target date), `joinday` (constituent dates in window), `hll` (daily HyperLogLog sketches)

### Component E: Monthly aggregation across dimensions
- **Purpose**: Calculate monthly active users across different dimensional breakdowns
- **Logic**: The windowed data is aggregated across multiple dimensions. For each target date and dimension combination, HyperLogLog sketches from all days in the 30-day window are merged together and the approximate distinct count is extracted. Four dimensional breakdowns are created: project level aggregation (project_dbt_tag), chain level aggregation, user type level aggregation, and product ID level aggregation. Each breakdown nullifies non-relevant dimensional fields and groups by the remaining dimensions. The result is approximate monthly active user counts for each dimension and time period.
- **Key fields**: `user_mau` (approximate distinct count), `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `timestamp`

### Final aggregation
- **Combining components**: The final model selects only the 'chain' and 'project_dbt_tag' dimensional breakdowns from the monthly active user calculations, filtering out user type and product ID breakdowns
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows updated daily, with each day representing the monthly active addresses for the period ending on that date
- **Final calculation**: The `user_mau` field is renamed to `active_addresses_monthly` to reflect that this metric represents unique addresses rather than users. Chain availability filtering is applied to ensure only data for available chains is included. Missing time periods are filled with zeros using the fill strategy, and the metric is partitioned by timestamp for efficient querying.

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

Unique addresses active over a rolling 30-day window.

CeloCELO

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown