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

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Stellar blockchain within any 7-day rolling period. This metric uses probabilistic counting via HyperLogLog sketches to efficiently handle overlapping users across time periods. The calculation identifies transaction senders (source accounts) and counts distinct addresses over rolling 7-day windows, providing insight into Stellar's weekly user engagement patterns.

## 2. Data sources

- **Stellar blockchain transactions**: Complete transaction records from the Stellar blockchain, including transaction metadata and sender addresses
- **Table modification timestamps**: Internal tracking data for incremental data processing (used for optimization, not metric calculation)

## 3. Step-by-step calculation

### Component A: Daily user extraction
- **Purpose**: Extract unique transaction sender addresses for each day
- **Logic**: Process all Stellar blockchain transactions and extract the `source_account` field (transaction sender) from each transaction. Group transactions by calendar day using daily timestamp truncation. Filter historical data to cover transactions before 2025-01-01, with recent data covering from 2025-01-01 onwards using incremental processing strategies. Cast all sender addresses to string format for consistency.
- **Key fields**: `source_account` becomes `user_address`, `block_timestamp` becomes daily `timestamp`, `transaction_hash` for transaction identification

### Component B: Daily active user aggregation  
- **Purpose**: Combine historical and recent user data with standardized metadata
- **Logic**: Union the historical and recent daily user extractions into a single dataset. Add metadata fields including chain identifier set to 'stellar', user type classified as 'Transaction sender', and null product identifier since Stellar operates as a single protocol. Each unique user address per day becomes one daily active user record.
- **Key fields**: `user_address` becomes `user_dau`, `chain` set to 'stellar', `user_type` set to 'Transaction sender', `product_id` set to null

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user lists into probabilistic counting sketches
- **Logic**: For each day, convert the list of unique user addresses into a HyperLogLog sketch with precision 15. This probabilistic data structure enables efficient counting of distinct users across time periods without storing actual address lists. Group by day, chain, user type, and product to maintain dimensional breakdowns.
- **Key fields**: `user_dau` addresses become `hll` sketches with 15-bit precision for ~1.6% standard error

### Component D: Rolling window construction
- **Purpose**: Build 7-day rolling windows for weekly calculations
- **Logic**: Create a datespine covering all calendar days in the analysis period. For each calendar day, construct a 7-day window that includes that day plus the previous 6 days. Join the datespine with the daily HLL sketches to associate each day's data with all relevant 7-day windows. This approach ensures complete coverage without gaps in the time series.
- **Key fields**: `timestamp` for target day, `joinday` for days within the 7-day window, associated `hll` sketches for each day in the window

### Component E: Weekly distinct user counting
- **Purpose**: Calculate distinct users across 7-day periods using probabilistic counting
- **Logic**: For each 7-day window, merge all daily HLL sketches using HyperLogLog merge operations. This combines the probabilistic representations to count distinct users who were active on any day within the 7-day period. Extract the final distinct count from the merged HLL sketch. Handle overlapping users efficiently without storing individual addresses.
- **Key fields**: Merged `hll` sketches become `user_wau` counts representing weekly active users

### Component F: Dimensional breakdowns
- **Purpose**: Create metric breakdowns across different analytical dimensions
- **Logic**: Calculate separate weekly active user metrics for different dimensional views: project-level aggregation (project_dbt_tag dimension) combining all data, chain-level aggregation maintaining chain identifier, user type aggregation grouping by user classification, and product-level aggregation grouping by product identifier. Each breakdown maintains the same HLL merge and extract logic while grouping by different dimensional attributes.
- **Key fields**: `dimensions` field indicating breakdown type (project_dbt_tag, chain, user_type, product_id), `user_wau` counts for each dimensional grouping

### Final aggregation
- **Combining components**: Select weekly active user data filtered to relevant dimensions (chain-level and project-level breakdowns only)
- **Currency conversion**: Not applicable - this is a count metric measured in number of addresses
- **Time aggregation**: Uses rolling 7-day windows where each day represents the count of distinct addresses active in that day plus the previous 6 days
- **Final calculation**: Map `user_wau` field to `active_addresses_weekly` field name for consistency with blockchain address metrics, apply standardization via finalize_metric macro to ensure consistent schema and fill missing days with zeros, and apply chain availability filtering to restrict results to available chain data periods

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

Unique active addresses over a rolling 7-day window.

StellarXLM

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape