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

## 1. Overview

Active addresses daily for Stellar measures the number of unique addresses that initiated at least one transaction on the Stellar network each day. This metric treats each unique transaction sender (source account) as an active address, providing insight into daily network usage and user engagement. The calculation uses probabilistic counting methods to efficiently handle large volumes of transaction data while maintaining accuracy.

## 2. Data sources

- **Stellar transaction records**: Complete transaction history from the Stellar blockchain, including block timestamps, transaction hashes, and source account addresses
- **Table metadata cache**: BigQuery system tables used for incremental processing optimization

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize raw Stellar transaction data for user activity analysis
- **Logic**: The process reads all Stellar blockchain transactions and extracts the `source_account` field (the transaction initiator) along with `block_timestamp` and `transaction_hash`. Timestamps are truncated to daily boundaries using day-level date truncation. The source account addresses are safely cast to string format to ensure consistent data typing. Data is split into two processing streams: historical data (before 2025-01-01) and recent data (from 2025-01-01 onward) for performance optimization
- **Key fields**: `timestamp` (daily truncated), `transaction_hash`, `user_address` (source account)

### Component B: User daily active calculation
- **Purpose**: Standardize user data with metadata and combine historical and recent periods
- **Logic**: The extracted transaction data from both time periods is combined using a union operation. Each record is enriched with standardized metadata including chain identifier set to 'stellar', user type labeled as 'Transaction sender', and product identifier set to null. The user address field is renamed to `user_dau` to align with the daily active user calculation framework
- **Key fields**: `timestamp`, `chain` (stellar), `user_type` (Transaction sender), `user_dau` (user address)

### Component C: HyperLogLog aggregation
- **Purpose**: Calculate unique daily active users across multiple dimensional breakdowns using probabilistic counting
- **Logic**: The system applies HyperLogLog probabilistic counting algorithms to efficiently calculate unique user counts. For each day, HyperLogLog sketches are initialized for each user address with precision parameter 15. The data is then grouped and aggregated across four different dimensions: project tag level (project_dbt_tag), chain level, user type level, and product identifier level. HyperLogLog merge operations combine the sketches, and extract operations convert them back to approximate unique counts
- **Key fields**: `timestamp`, `dimensions`, `chain_id`, `user_type`, `product_id`, `user_dau` (unique count)

### Final aggregation
- **Combining components**: The final model filters the HyperLogLog aggregated results to include only the 'chain' and 'project_dbt_tag' dimensional breakdowns, which are the relevant perspectives for active addresses reporting
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: Data is already aggregated to daily boundaries through the initial timestamp truncation
- **Final calculation**: The `user_dau` field is renamed to `active_addresses_daily` to reflect the metric's purpose. The finalization macro applies standardized schema formatting and fills any missing days with zero values to ensure complete time series data. Chain availability filtering is applied to respect data availability constraints for the Stellar network

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

Unique active addresses over a fixed 24-hour window.

StellarXLM

Active addresses (daily)

Active addresses (daily)

Competitive landscape