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

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Celo L1 (legacy) blockchain within a 7-day rolling window. This metric provides insight into user engagement and network adoption by tracking distinct transaction senders over weekly periods. The calculation uses HyperLogLog sketches for efficient approximate distinct counting, which is essential for handling large-scale blockchain transaction data while maintaining reasonable computational performance.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Celo L1 (legacy) blockchain transaction records**: Complete transaction history from the Celo L1 (legacy) network containing transaction metadata including timestamps, transaction hashes, and sender addresses
- **Transaction sender addresses**: The `from_address` field from each transaction, representing the address that initiated the transaction
- **Timestamp data**: Block timestamps for each transaction, used to determine daily boundaries and rolling window calculations
- **Protocol transition metadata**: Built-in logic to handle Celo L1 (legacy)'s transition from L1 to L2 on March 26, 2025, affecting product classification

## 3. Step-by-step calculation

### Component A: Transaction sender extraction
- **Purpose**: Identify all transaction senders and classify them by protocol version
- **Logic**: Extract the sender address (`from_address`), timestamp (`block_timestamp`), and transaction hash from each Celo L1 (legacy) transaction record. Apply protocol classification based on timestamp: transactions before 2025-03-26 are classified as Celo L1 (legacy) L1 with product identifier 'Celo L1 (legacy)' and market sector 'blockchains_l1', while transactions on or after this date are classified as Celo L1 (legacy) L2 with product identifier 'Celo L1 (legacy) L2' and market sector 'blockchains_l2'. All senders are labeled with user type 'Transaction sender'
- **Key fields**: `from_address` as the active address identifier, `block_timestamp` for temporal grouping, `transaction_hash` for transaction identification, `product_id` and `market_sector_id` for protocol classification

### Component B: Daily active user calculation
- **Purpose**: Calculate daily distinct active addresses by aggregating transaction senders within each day
- **Logic**: Group transaction records by day using timestamp truncation to day boundaries. For each day, count distinct sender addresses to determine daily active users. Preserve protocol classification fields (chain, user type, market sector, business segment, product identifier) for dimensional analysis
- **Key fields**: `timestamp` truncated to day granularity, `user_address` (the distinct sender addresses), classification fields maintained from the extraction step

### Component C: HyperLogLog sketch preparation
- **Purpose**: Convert daily active user data into HyperLogLog sketches for efficient rolling window aggregation
- **Logic**: For each day, initialize HyperLogLog sketches from the daily active user addresses using a 15-bit precision parameter. Group sketches by timestamp, chain identifier, user type, and product identifier. This probabilistic data structure enables efficient approximate distinct counting across time windows without storing all individual addresses
- **Key fields**: `timestamp` for temporal organization, `hll` containing the HyperLogLog sketch of daily active addresses, dimensional grouping fields

### Component D: Rolling 7-day window creation
- **Purpose**: Create rolling 7-day windows for each date to calculate weekly active address counts
- **Logic**: Generate a complete datespine covering the full time range to ensure no missing dates. For each date in the spine, create a 7-day lookback window consisting of the current day plus the 6 preceding days. Join this window specification with the daily HyperLogLog sketches to identify all sketches that fall within each 7-day window
- **Key fields**: `timestamp` for the window end date, `joinday` representing each day within the 7-day lookback period, associated HyperLogLog sketches for aggregation

### Component E: Weekly aggregation with dimensional breakdowns
- **Purpose**: Merge HyperLogLog sketches across 7-day windows and create multiple dimensional views
- **Logic**: For each 7-day window, merge all HyperLogLog sketches falling within that period using HLL merge operations, then extract the final approximate distinct count. Create four dimensional breakdowns: project-level aggregation (combining all dimensions), chain-level aggregation (grouping by chain identifier), user type aggregation, and product identifier aggregation. Each breakdown preserves relevant dimensional fields while setting others to null
- **Key fields**: `user_wau` containing the weekly active address count, `dimensions` indicating the breakdown level, relevant dimensional identifiers based on breakdown type

### Final aggregation
- **Combining components**: Select only the 'chain' and 'project_dbt_tag' dimensional breakdowns from the weekly aggregation results, filtering out user type and product identifier breakdowns
- **Currency conversion**: Not applicable for this address-based metric
- **Time aggregation**: Uses rolling 7-day windows where each date represents the end of a weekly period, with the count including active addresses from that date and the 6 preceding days
- **Final calculation**: Rename the `user_wau` field to `active_addresses_weekly` to reflect that this metric represents weekly active addresses rather than generic user counts. Apply the finalization macro to standardize schema and fill any missing dates with zero values, ensuring complete time series data

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

Unique active addresses over a rolling 7-day window.

CeloCELO

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown