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

Bifrost is the Staking Yield Layer app-chain for stablecoins, RWAs, and DeFi, powered by the Polkadot Relay chain.

BNC holders own and govern the protocol. Bifrost’s investors include OKX Ventures, Long Hash Ventures, etc.

website

github

twitter

discord

etherscan

Blockchains (L2)

Bifrost

# Bifrost Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who have performed transactions on the Bifrost.io protocol within a rolling 30-day period. This metric provides insight into user engagement and protocol adoption by tracking distinct addresses that interact with both the native Substrate chain and the integrated EVM environment. The calculation uses HyperLogLog data structures to efficiently count distinct users across multiple dimensions and time windows.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Bifrost.io substrate extrinsics**: Native blockchain transaction records containing user IDs for all substrate-based transactions
- **Bifrost.io EVM events**: Event logs from the ethereum pallet, specifically `Executed` events that capture EVM transaction activity with sender addresses extracted from event data
- **Chain availability metadata**: External data used to filter and validate chain operational status and data quality

## 3. Step-by-step calculation

### Component A: User identification and daily aggregation

- **Purpose**: Identifies unique daily active users from both substrate and EVM transaction activity
- **Logic**: Extracts transaction senders from two data streams. For native substrate transactions, uses the `id` field from extrinsics as the user identifier. For EVM transactions, filters events where `event_pallet` equals 'ethereum' and `event_method` equals 'Executed', then extracts the user address from the first element of the `event_data` array. Both streams are classified as 'Transaction sender' user type and tagged with appropriate chain identifiers ('bifrostio' for substrate, 'Bifrost EVM' for EVM)
- **Key fields**: `block_timestamp` for temporal grouping, `user_address` or `id` for user identification, `chain` for network classification, `user_type` set to 'Transaction sender'

### Component B: Daily active user preprocessing

- **Purpose**: Aggregates identified users into daily distinct counts with dimensional attributes
- **Logic**: Groups user activity by day using timestamp truncation to daily granularity. Maintains dimensional attributes including chain, user type, market sector, business segment, and product identifiers. Applies chain availability filtering to ensure data quality and exclude periods when chains were not operational
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique user addresses, dimensional fields for later breakdown analysis

### Component C: HyperLogLog sketch creation

- **Purpose**: Converts daily user data into HyperLogLog data structures for efficient distinct counting
- **Logic**: Initializes HLL sketches for each daily user set using precision parameter 15. Groups data by timestamp, chain, user type, and product dimensions to create separate sketches for each combination. This enables efficient merging of user sets across time periods without double-counting users who are active on multiple days
- **Key fields**: `hll` containing HyperLogLog sketches, dimensional grouping fields for later aggregation

### Component D: Rolling window construction

- **Purpose**: Creates 30-day rolling windows to capture monthly activity periods
- **Logic**: Generates a complete datespine covering all days in the analysis period to ensure no gaps in the time series. For each target day, creates a 30-day lookback window by joining with all days from 29 days prior through the target day. This approach ensures consistent 30-day windows even when some days have no activity
- **Key fields**: `timestamp` for the target day, `joinday` for days within the 30-day window

### Component E: Window-based HLL aggregation

- **Purpose**: Combines HLL sketches across 30-day periods to calculate monthly active users
- **Logic**: Joins the rolling window structure with HLL sketches to collect all relevant daily sketches for each 30-day period. Groups by target timestamp and dimensions, then merges HLL sketches using `hll_count.merge_partial()` to create unified sketches representing all unique users active within each 30-day window
- **Key fields**: `hll` containing merged sketches for 30-day periods, dimensional grouping maintained for breakdown analysis

### Component F: Dimensional breakdowns

- **Purpose**: Creates multiple analytical views of MAU data across different dimensions
- **Logic**: Generates four separate breakdowns from the windowed HLL data. Project-level breakdown aggregates all dimensions to show overall protocol MAU. Chain-level breakdown maintains chain separation to show MAU by network. User-type breakdown groups by user classification. Product-level breakdown segments by product identifiers. Each breakdown extracts final user counts from merged HLL sketches using `hll_count.extract()`
- **Key fields**: `user_mau` containing final distinct user counts, `dimensions` indicating the breakdown type, relevant dimensional fields populated based on breakdown type

### Final aggregation

- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a unified dataset with different analytical perspectives
- **Schema standardization**: The `finalize_metric_user_mau` macro applies standard schema formatting, adds metadata fields, and implements a fill-zeros strategy to populate missing time periods with zero values
- **Time boundaries**: Incremental processing uses monthly partitioning with configurable lookback periods to balance data freshness with processing efficiency
- **Final calculation**: The metric represents the distinct count of user addresses that performed at least one transaction within any 30-day rolling period, calculated using probabilistic HyperLogLog structures for scalability and accuracy

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

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

BifrostBNC

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown