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 addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have performed at least one transaction on the Bifrost.io blockchain within a rolling 30-day period. This metric serves as a proxy for user activity and network adoption, treating each unique blockchain address as representing an active user. The calculation combines data from both Bifrost.io's native substrate layer and its EVM compatibility layer to capture comprehensive user activity across the entire network.

## 2. Data sources

The methodology relies on the following raw data sources:

- **Bifrost.io substrate extrinsics**: Native blockchain transaction records containing transaction senders and execution details from the substrate-based layer of Bifrost.io
- **Bifrost.io EVM events**: Event logs from the EVM compatibility layer, specifically `ethereum` pallet events with `Executed` method that capture Ethereum-style transactions executed on Bifrost.io
- **Transaction metadata**: Block timestamps and execution context for both substrate and EVM transactions to enable time-based analysis

## 3. Step-by-step calculation

### Component A: User address extraction
- **Purpose**: Identifies all unique user addresses that perform transactions across both substrate and EVM layers
- **Logic**: Extracts transaction sender addresses from two distinct data sources. For native substrate transactions, uses the `id` field directly as the user address. For EVM layer transactions, filters for ethereum pallet events with `Executed` method and extracts the user address from the first element of the `event_data` array. Each record includes block timestamp, chain identifier, and user classification metadata
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` for unique identification, `chain` distinguishing between 'bifrostio' and 'Bifrost EVM' layers, `user_type` always set to 'Transaction sender'

### Component B: Daily active user calculation
- **Purpose**: Aggregates user addresses into daily distinct counts using efficient probabilistic data structures
- **Logic**: Groups extracted user addresses by day using timestamp truncation, then creates HyperLogLog sketches for each daily cohort. This approach enables efficient storage and computation of distinct counts while maintaining accuracy. Filters data based on incremental processing windows to optimize performance for regular updates
- **Key fields**: `timestamp` truncated to daily granularity, `user_dau` containing the unique user address, `hll` HyperLogLog sketch initialized with precision 15 for distinct counting

### Component C: Monthly active user aggregation
- **Purpose**: Computes rolling 30-day active user counts across multiple dimensional breakdowns
- **Logic**: Creates a comprehensive datespine covering all days in the analysis period, then builds rolling 30-day windows for each date. For each day, identifies the preceding 30-day period and merges HyperLogLog sketches from all days within that window. Performs this calculation across four dimensional breakdowns: project-level aggregation, chain-level breakdown, user type segmentation, and product-level analysis. Uses HyperLogLog merge operations to efficiently combine daily sketches while maintaining distinct count accuracy
- **Key fields**: `timestamp` for the end date of each 30-day window, `dimensions` indicating breakdown type ('project_dbt_tag', 'chain', 'user_type', 'product_id'), `user_mau` containing the distinct user count over the 30-day period

### Final aggregation
- **Combining components**: Monthly active user data is filtered to include only chain-level and project-level dimensions, then directly mapped to active addresses since blockchain addresses represent users
- **Currency conversion**: Not applicable for this address-counting metric
- **Time aggregation**: Uses rolling 30-day windows ending on each date, providing continuous monthly active address tracking rather than calendar month boundaries
- **Final calculation**: The `user_mau` value from the monthly aggregation becomes the `active_addresses_monthly` metric directly, as each unique address represents one active user. Applied chain availability filtering ensures only supported chains are included in final results.

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

Unique addresses active over a rolling 30-day window.

BifrostBNC

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown