Collators aggregate parachain transactions block candidates and producing state transition proofs for validators based on those blocks.

Phala is a specialized privacy-preserving cloud computing blockchain powered by Polkadot Relay chain.

PHA holders own and govern the protocol. Phala’s investors include IOSG Ventures, Incuba Alpha, Candaq Fintech Group, and others.

website

twitter

discord

github

etherscan

Blockchains (L2)

Phala

# Phala Active addresses (monthly) Methodology

## 1. Overview

The monthly active addresses metric for Phala Network measures the number of unique addresses that have submitted at least one extrinsic (transaction) on the Phala Network within a rolling 30-day period. This metric answers the question "How many distinct users are actively transacting on Phala Network each month?" and uses a rolling 30-day window approach where each day's metric represents the count of unique addresses active during that day and the previous 29 days. For blockchain projects like Phala Network, active addresses are equivalent to active users since each transaction is associated with a unique wallet address.

## 2. Data sources

The calculation relies on these raw data sources:
- **Phala Network extrinsics**: Raw extrinsic (transaction) data from the Phala Network blockchain, containing transaction sender addresses and timestamps
- **Substrate blockchain transaction logs**: Native Phala Network transaction records with block timestamps and transaction identifiers
- **Blockchain event data**: Transaction-level data from Phala Network's Substrate-based infrastructure

## 3. Step-by-step calculation

### Component A: User extraction from extrinsics
- **Purpose**: Identify unique user addresses from raw Phala Network transaction data
- **Logic**: Extract transaction sender addresses from Phala Network extrinsics data, treating each unique sender as a distinct user. Each record includes the `id` field representing the transaction sender address and `block_timestamp` indicating when the transaction occurred. Classify all senders as "Transaction sender" user type and categorize Phala as a layer-2 blockchain in the blockchains market sector.
- **Key fields**: `block_timestamp` for timing, `id` field as the `user_address`, chain identifier as 'phala', and user classification metadata

### Component B: Daily active user aggregation
- **Purpose**: Calculate distinct active users for each day
- **Logic**: Group the extracted user data by day using timestamp truncation to day granularity. For each day, count distinct user addresses that submitted at least one extrinsic. Create one record per unique user per day, effectively deduplicating multiple transactions from the same address within a single day. Use incremental processing to efficiently update only recent dates.
- **Key fields**: `timestamp` truncated to day, `user_address` as the unique identifier for daily deduplication

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into memory-efficient probabilistic data structures for large-scale distinct counting
- **Logic**: Transform the daily active user data into HyperLogLog (HLL) sketches for each day. HLL sketches allow efficient approximate counting of distinct elements across large datasets without storing all individual values. Initialize HLL sketches with precision parameter 15 for each combination of day, chain, user type, and product dimensions.
- **Key fields**: `hll` sketches containing compressed representations of daily active user sets

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for monthly active user calculation
- **Logic**: Generate a date spine covering all days from the earliest user activity to the current date minus one day. For each day in the spine, create a 30-day window consisting of that day plus the previous 29 days. Use array generation and unnesting operations to create join relationships between each day and all days in its corresponding 30-day window.
- **Key fields**: `timestamp` for the target date and `joinday` for each day within the 30-day window

### Component E: Window-based HLL aggregation
- **Purpose**: Combine HLL sketches across 30-day windows to calculate monthly active users
- **Logic**: Join the rolling window structure with the daily HLL sketches to collect all HLL data for each 30-day period. For each target day, gather HLL sketches from all days within its 30-day window. This creates the foundation for merging sketches to count distinct users across the entire monthly period.
- **Key fields**: HLL sketches associated with each day in the rolling windows

### Component F: Dimensional breakdown calculation
- **Purpose**: Calculate monthly active users across different dimensional groupings
- **Logic**: Create separate MAU calculations for four different dimensional breakdowns: project level (project_dbt_tag), chain level, user type level, and product level. For each breakdown, group the windowed HLL data by the appropriate dimensions and merge HLL sketches using HLL merge operations. Extract the distinct count from the merged sketches to get the final MAU value. Combine all dimensional breakdowns into a unified result set.
- **Key fields**: `dimensions` indicating the breakdown type, `user_mau` containing the distinct user count for each dimension

### Final aggregation
- **Combining components**: The dimensional MAU calculations are combined using union operations to create a single dataset containing MAU values for all dimensional breakdowns. The final model selects MAU data filtered to 'chain' and 'project_dbt_tag' dimensions only.
- **Currency conversion**: Not applicable for this count-based metric
- **Time aggregation**: Uses rolling 30-day windows where each day's metric represents unique users active during that day and the previous 29 days, providing a smoothed monthly view that updates daily
- **Final calculation**: The metric renames `user_mau` to `active_addresses_monthly` and applies schema finalization, recognizing that for blockchain projects, monthly active users and monthly active addresses represent the same concept since each user is identified by their unique wallet address

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

Unique addresses active over a rolling 30-day window.

PhalaPHA

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown