Validators process transactions and receive fees from users (supply-side fees). DA costs for users are reflected in the transactions fees paid.

Celestia is a proof of stake blockchain optimized for data availability (DA). Celestia was founded by Mustafa Al-Bassam, etc. and launched in 2023.

TIA holders own and govern the protocol. They currently do not take a cut of the total transaction fees paid by users (revenue). Celestia's investors include Polychain Capital, Placeholder, Coinbase Ventures, etc.

github

twitter

discord

website

Blockchains (L1)

Celestia

# Celestia Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Celestia measures the number of unique addresses that have sent transactions on the Celestia blockchain within a rolling 30-day window. This metric answers the question "How many unique users are actively transacting on Celestia over the past month?" The calculation uses a rolling window approach rather than calendar months to provide a more current view of user activity, and employs HyperLogLog probabilistic data structures for efficient distinct counting across large datasets.

## 2. Data sources

- **Celestia blockchain message events**: Raw Celestia blockchain transaction logs containing message events with transaction metadata and sender information
- **Table modification tracking system**: Internal system tracking last modification times for incremental processing optimization

## 3. Step-by-step calculation

### Component A: User identification from blockchain events
- **Purpose**: Extract user addresses from Celestia blockchain transactions
- **Logic**: Process Celestia blockchain message events where `event_type` equals `message`. Use a JavaScript user-defined function to parse JSON-formatted message attributes and extract the `sender` field value, which represents the transaction originator address. Each message event represents a transaction, and the sender address is classified as a "Transaction sender" user type. All users are categorized under the "blockchains_l1" market sector and "blockchain" business segment, with no specific product differentiation (product_id is null).
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for transaction identification, `event_attributes` containing JSON with sender information, extracted `user_address` as the unique user identifier

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct user counts as the foundation for MAU calculation
- **Logic**: Group the extracted user data by day using timestamp truncation to the day level. For each day, count distinct user addresses grouped by chain, user type, and product dimensions. This creates a daily active users (DAU) dataset that serves as input for the rolling MAU calculation. Apply incremental processing logic to only process recent data when updating existing calculations.
- **Key fields**: `timestamp` truncated to day grain, `chain` identifier, `user_type` classification, `product_id` grouping, `user_dau` as the distinct user address

### Component C: HyperLogLog conversion for efficient distinct counting
- **Purpose**: Convert daily user lists into probabilistic data structures for efficient aggregation
- **Logic**: Transform the daily distinct user counts into HyperLogLog (HLL) sketches using BigQuery's `hll_count.init()` function with precision parameter 15. This probabilistic data structure allows efficient merging of user sets across multiple days without storing individual addresses, enabling scalable distinct counting for the rolling window calculation.
- **Key fields**: `hll` containing the HyperLogLog sketch representation of daily distinct users, grouped by timestamp, chain, user type, and product dimensions

### Component D: Rolling window datespine creation
- **Purpose**: Establish complete time coverage and create rolling 30-day windows
- **Logic**: Generate a datespine covering all days from the earliest available data to the current date using `generate_timestamp_array()`. For each day in the datespine, create associations with the previous 29 days to establish 30-day rolling windows. This ensures every day has a complete window even if some days have no transaction activity. Use `unnest()` with `generate_timestamp_array()` to create the day-to-lookback-day mappings for window construction.
- **Key fields**: `timestamp` as the target date, `joinday` representing each day within the 30-day lookback window for that target date

### Component E: Rolling window user aggregation
- **Purpose**: Calculate MAU by merging users across 30-day windows
- **Logic**: Join the rolling window datespine with the daily HLL user data to create 30-day windows of user activity. For each target date, collect the HLL sketches from that date and the previous 29 days. Merge these HLL sketches using `hll_count.merge_partial()` to combine the probabilistic user sets, then extract the final distinct count using `hll_count.extract()`. This produces the rolling 30-day unique user count for each dimensional combination.
- **Key fields**: `user_mau` as the final distinct user count over the 30-day window, maintained with full dimensional breakdown

### Component F: Dimensional breakdowns
- **Purpose**: Create MAU metrics across different analytical dimensions
- **Logic**: Generate separate aggregations for four analytical dimensions: project-level (all Celestia users combined), chain-level (though Celestia is single-chain), user-type-level (transaction senders), and product-level (currently null for Celestia). For each dimension, group the windowed data appropriately and merge HLL sketches to calculate distinct users. Set non-relevant dimension fields to null for each breakdown to maintain consistent schema structure.
- **Key fields**: `dimensions` indicating the breakdown type, relevant dimension fields populated while others set to null, `user_mau` as the distinct count for each dimensional grouping

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) into a single result set with consistent schema structure
- **Time aggregation**: Maintain daily grain timestamps representing the end date of each 30-day rolling window
- **Final calculation**: The MAU value represents the distinct count of user addresses that sent at least one transaction during the 30-day period ending on each date, calculated using HyperLogLog probabilistic counting for scalability and efficiency

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

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

CelestiaTIA

Active users (monthly)

Active users (monthly)

Competitive landscape