Build once, connect everywhere. Hyperbridge gives developers the secure infrastructure to scale applications across any network.

website

twitter

github

discord

Bridges

Hyperbridge

# Hyperbridge Active addresses (monthly) Methodology

## 1. Overview

Active addresses monthly for Hyperbridge measures the number of unique addresses that interact with the Hyperbridge protocol within any 30-day rolling window. This metric captures user engagement across both the native Hyperbridge parachain and EVM-compatible chains where Hyperbridge contracts are deployed. The calculation uses HyperLogLog probabilistic data structures to efficiently compute distinct user counts across large datasets and multiple chains.

## 2. Data sources

The calculation relies on these raw blockchain data sources:

- **Native Hyperbridge extrinsics**: Records of all transactions and operations executed on the Hyperbridge parachain, containing extrinsic IDs that serve as user identifiers
- **EVM transaction records**: Transaction data from eight supported chains (Arbitrum, Ethereum, Optimism, Base, BSC, Gnosis, Polygon, and Unichain) filtered to interactions with specific Hyperbridge protocol contracts
- **Hyperbridge contract addresses**: Hardcoded lists of protocol contract addresses on each EVM chain, including Host contracts, Handler contracts, IntentGateway contracts, and TokenGateway contracts
- **Chain availability filters**: Configuration data that determines which chains should be included in final metrics based on data availability periods

## 3. Step-by-step calculation

### Component A: Native chain user extraction
- **Purpose**: Identifies users interacting with the native Hyperbridge parachain
- **Logic**: Extracts all extrinsics from Hyperbridge chain transaction records, treating each extrinsic ID as a unique user identifier. Timestamps are truncated to daily boundaries for aggregation. Each user interaction is classified as product type `Hyperbridge Substrate` with user type `Transaction sender`
- **Key fields**: `block_timestamp` for daily aggregation, `extrinsic_id` as `user_address`, constant `chain` value of `hyperbridge`

### Component B: EVM chain user extraction  
- **Purpose**: Identifies users interacting with Hyperbridge contracts on EVM-compatible chains
- **Logic**: Processes transaction records from eight EVM chains, filtering to only include transactions sent to predefined Hyperbridge contract addresses. Each chain has a specific set of contract addresses representing different protocol components like Host contracts, Handler contracts, IntentGateway contracts, and TokenGateway contracts. Transaction senders are extracted as user addresses and classified as product type `Hyperbridge App`
- **Key fields**: `block_timestamp` for daily aggregation, `from_address` as `user_address`, `to_address` filtered against contract address lists, `chain` indicating the source blockchain

### Component C: Daily user aggregation
- **Purpose**: Combines users from both native and EVM chains into daily distinct counts
- **Logic**: Unions user records from native Hyperbridge extrinsics and EVM transactions, then creates distinct user records grouped by day, chain, user type, and product. This eliminates duplicate interactions by the same user on the same day while preserving dimensional breakdowns
- **Key fields**: Daily truncated `timestamp`, `chain`, `user_type`, `product_id`, distinct `user_address` values

### Component D: HyperLogLog sketch creation
- **Purpose**: Converts daily user lists into probabilistic data structures for efficient aggregation
- **Logic**: Groups daily user records and creates HyperLogLog sketches with precision parameter 15 for each combination of day, chain, user type, and product. These sketches enable approximate distinct counting while significantly reducing memory requirements for downstream processing
- **Key fields**: `timestamp`, dimensional grouping fields, `hll` sketch containing compressed user data

### Component E: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for monthly active user calculation
- **Logic**: Generates a complete datespine covering all days from the earliest user data to yesterday. For each day in the datespine, creates a 30-day window by generating timestamps for the current day plus the previous 29 days. Joins this window data with the daily HLL sketches to ensure all relevant user activity is captured within each rolling period
- **Key fields**: `timestamp` for the window end date, `joinday` for dates within the window, `hll` sketches for each day in the window

### Component F: HyperLogLog sketch merging
- **Purpose**: Combines user activity across 30-day windows to calculate monthly active users
- **Logic**: For each 30-day window, merges all HyperLogLog sketches within that period using HLL merge operations. This probabilistic union operation estimates the number of distinct users active within the entire 30-day period, accounting for users who may have been active on multiple days
- **Key fields**: Window `timestamp`, merged `hll` sketches, dimensional grouping fields

### Component G: Dimensional aggregation
- **Purpose**: Breaks down monthly active users across different analytical dimensions
- **Logic**: Calculates monthly active users at four different aggregation levels: project level (all chains combined), individual chain level, user type level (transaction senders), and product level (native chain vs EVM apps). Each breakdown extracts the final distinct count from merged HLL sketches and assigns appropriate dimensional labels
- **Key fields**: `dimensions` indicating aggregation level, `chain_id` for chain-specific breakdowns, `user_mau` containing extracted HLL counts

### Final aggregation
- **Combining components**: The monthly active user calculations from all dimensional breakdowns are combined using union operations, creating a comprehensive dataset with different aggregation levels
- **Currency conversion**: Not applicable for this user count metric
- **Time aggregation**: Uses 30-day rolling windows with daily granularity, where each day represents the end of a 30-day lookback period
- **Final calculation**: Selects only the `chain` and `project_dbt_tag` dimensional breakdowns, renames `user_mau` to `active_addresses_monthly`, and applies standardized metric finalization including zero-filling for missing periods and chain availability filtering

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

Unique addresses active over a rolling 30-day window.

HyperbridgeBRIDGE

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown