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

Stellar is a distributed ledger for transfer and store of value (a blockchain). Stellar was founded by Jed McCaleb launched in 2014.

XLM holders own and govern the protocol. They currently take all of the total transaction fees paid by users (revenue).

github

twitter

discord

etherscan

website

Blockchains (L1)

Stellar

# Stellar Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on the Stellar network within a 30-day rolling window. This metric answers the fundamental question: "How many unique users are actively transacting on Stellar each month?" The calculation uses HyperLogLog probabilistic counting for efficient computation and applies a 30-day rolling window to provide smooth, continuous monthly measurements rather than calendar month boundaries.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Stellar transaction records**: Complete blockchain transaction data including block timestamps, transaction hashes, and source account addresses from the Stellar network
- **Incremental processing metadata**: Table modification timestamps used for efficient incremental data processing (does not affect the actual metric calculation)

## 3. Step-by-step calculation

### Component A: Transaction user extraction
- **Purpose**: Identify unique daily active users from Stellar transaction data
- **Logic**: Extract all Stellar transactions and identify the `source_account` field as the transaction sender (user address). Truncate `block_timestamp` to day level to create daily user activity records. The data is split into two processing streams: historical data (before 2025-01-01) and recent data (2025-01-01 onwards) for efficient incremental processing. Each transaction creates a record linking the user address to the day they were active.
- **Key fields**: `source_account` becomes `user_address`, `block_timestamp` becomes daily `timestamp`, `transaction_hash` for transaction identification

### Component B: Daily active users aggregation  
- **Purpose**: Create daily active user (DAU) records with metadata for further processing
- **Logic**: Combine both historical and recent transaction data streams to create comprehensive daily active user records. Each record represents a unique user active on a specific day, tagged with chain identifier ('stellar'), user type ('Transaction sender'), and null product identifiers since Stellar operates as a single protocol without sub-products.
- **Key fields**: `timestamp` (day-level), `user_address` as `user_dau`, `chain` identifier, `user_type` classification

### Component C: Monthly active users calculation using HyperLogLog
- **Purpose**: Calculate 30-day rolling Monthly Active Users (MAU) using probabilistic counting
- **Logic**: Apply HyperLogLog sketching to daily user records for efficient unique counting. Create a datespine covering all days in the analysis period, then for each day, construct a 30-day lookback window (current day plus 29 previous days). Join the datespine with daily HLL sketches to create rolling windows. Merge HLL sketches across each 30-day period and extract the estimated unique user count. This approach provides smooth rolling MAU calculations rather than calendar month boundaries.
- **Key fields**: `hll` sketches for probabilistic counting, `timestamp` for window boundaries, merged HLL results as `user_mau`

### Component D: Multi-dimensional breakdowns
- **Purpose**: Provide MAU metrics across different analytical dimensions
- **Logic**: Break down the same underlying MAU calculation into multiple dimensional views: project-level (aggregating all Stellar activity), chain-level (maintaining Stellar chain identifier), user-type level (maintaining 'Transaction sender' classification), and product-level (null values since no sub-products exist). Each breakdown uses the same HLL merge logic but groups by different dimensional attributes.
- **Key fields**: `dimensions` field indicating breakdown type, dimension-specific identifiers (`chain_id`, `user_type`, `product_id`), consistent `user_mau` values

### Final aggregation: Active addresses monthly
- **Purpose**: Convert MAU into the final active addresses metric
- **Logic**: Filter the multi-dimensional MAU results to include only 'chain' and 'project_dbt_tag' dimensions, which represent the primary analytical views for active addresses. Rename the `user_mau` field to `active_addresses_monthly` to reflect the business terminology. Apply schema standardization through the finalize metric macro, which adds consistent metadata fields, handles data type formatting, and fills any missing time periods with zero values to ensure complete time series data.
- **Key fields**: `active_addresses_monthly` (renamed from `user_mau`), `dimensions` filtered to relevant breakdowns, standardized schema fields

The final metric represents unique Stellar addresses that initiated at least one transaction within each 30-day rolling window, providing a smooth measure of monthly user activity on the network.

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

Unique addresses active over a rolling 30-day window.

StellarXLM

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape