Allbridge Core allows users to send stablecoins from one chain to another almost immediately by using native liquidity pools deployed across 5 EVM and non-EVM blockchains. Liquidity providers receive the majority of transfer fees paid by users (supply-side fees).

Allbridge Core is a cross-chain stablecoin bridge. Allbridge Core was co-founded by Yuriy Savchenko and Andriy Velykyy, and was launched in September 2022.

The Allbridge team own and govern the protocol. They currently take a cut of the transfer fees paid by the users (revenue). Allbridge Core’s investors include Race Capital and others.

github

twitter

discord

website

Bridges

Allbridge Core

# Allbridge Core Active users (weekly) Methodology

## 1. Overview

The Allbridge weekly active users (WAU) metric measures the number of unique addresses that interact with Allbridge's cross-chain bridge protocol within a 7-day rolling window. This metric provides insight into weekly user engagement and adoption of Allbridge's bridge services across multiple blockchain networks. The calculation uses HyperLogLog data structures to efficiently count unique users across different dimensional breakdowns while maintaining accuracy for large datasets.

## 2. Data sources

The calculation relies on several blockchain data sources:
- **Bridge contract events**: Parsed `TokensSent` events from Allbridge v1 and v2 Bridge contracts on BSC, Ethereum, and Polygon networks
- **Cross-chain events**: Parsed `TokensReceived` events from Allbridge v2 Bridge contracts, specifically capturing transactions originating from non-EVM chains
- **Transaction metadata**: Block timestamps and transaction hashes from supported blockchain networks
- **Cross-chain message data**: Encoded message parameters containing origin chain identifiers and recipient address information for cross-chain transactions

## 3. Step-by-step calculation

### Component A: User identification from bridge events
- **Purpose**: Identifies all unique user addresses interacting with Allbridge bridge contracts
- **Logic**: Extracts user addresses from two types of bridge events across BSC, Ethereum, and Polygon. For `TokensSent` events, the `recipient` parameter directly provides the user address. For `TokensReceived` events, applies special processing to extract recipient addresses from hex-encoded message data, specifically targeting transactions from non-EVM chains like Solana and Tron. Prevents double-counting by filtering `TokensReceived` events to only include those with origin chain IDs 3 (Tron) and 4 (Solana)
- **Key fields**: `recipient` addresses from sent events, extracted addresses from `message` data in received events, `block_timestamp` for temporal grouping, `transaction_hash` for deduplication, and `origin_chain_id` for cross-chain filtering

### Component B: Daily active users aggregation  
- **Purpose**: Converts raw user interactions into daily unique user counts
- **Logic**: Groups all user addresses by day using timestamp truncation to daily boundaries. Creates distinct user counts per day while maintaining dimensional attributes like chain, user type, market sector, business segment, and product ID. Each daily record represents the set of unique addresses that interacted with Allbridge on that specific day
- **Key fields**: Daily truncated `timestamp`, `chain` identifier, `user_type` classification, `market_sector_id` and `business_segment_id` for categorization, `product_id` for product-specific analysis, and `user_address` for uniqueness tracking

### Component C: HyperLogLog initialization for efficient counting
- **Purpose**: Prepares daily user data for efficient weekly aggregation using probabilistic data structures
- **Logic**: Initializes HyperLogLog data structures for each daily user dataset, enabling efficient unique counting when aggregating across multiple days. Uses a precision parameter of 15 to balance memory usage with counting accuracy. Groups data by timestamp, chain, user type, and product ID to maintain dimensional breakdowns
- **Key fields**: `hll` data structure containing encoded user information, dimensional grouping fields for maintaining breakdown categories

### Component D: Continuous datespine creation
- **Purpose**: Ensures complete time series coverage for accurate rolling window calculations
- **Logic**: Generates a continuous daily timestamp series from the earliest available data date through yesterday. Uses timestamp array generation to create every single day in the range, preventing gaps that could affect rolling window calculations. For incremental updates, limits the datespine to relevant time periods based on the last modification time
- **Key fields**: Complete series of daily `timestamp` values covering the entire analysis period

### Component E: Seven-day rolling window construction
- **Purpose**: Creates 7-day lookback windows for each day to calculate weekly active users
- **Logic**: For each day in the datespine, generates the 6 preceding days plus the current day to form a 7-day window. Uses timestamp array generation to create the window days, then joins with the daily HLL data to collect user data for each window period. This approach ensures every day has a complete 7-day lookback window for consistent WAU calculation
- **Key fields**: `timestamp` for the window end date, `joinday` representing each day within the 7-day window, HLL data structures for each day in the window

### Component F: HyperLogLog merging for unique weekly counts
- **Purpose**: Combines daily user data within each 7-day window to calculate unique weekly active users
- **Logic**: Merges HyperLogLog data structures across all days within each 7-day window using HLL merge operations. This efficiently calculates the number of unique users who were active on any day within the window, automatically handling cases where users were active on multiple days. Extracts the final count from the merged HLL structure
- **Key fields**: Merged `hll` structures representing unique users across the 7-day period, extracted `user_wau` counts

### Component G: Dimensional breakdowns
- **Purpose**: Creates multiple views of weekly active users across different analytical dimensions
- **Logic**: Generates separate aggregations for project-level (overall), chain-specific, user type, and product ID breakdowns. Each breakdown maintains the same WAU calculation logic but groups data differently. Uses null casting for dimensions not relevant to each breakdown to maintain consistent schema structure. Combines all breakdowns using union operations to create a comprehensive dataset
- **Key fields**: `dimensions` identifier specifying the breakdown type, dimension-specific fields like `chain_id`, `user_type`, and `product_id`, `user_wau` counts for each dimensional combination

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single comprehensive dataset containing WAU metrics across different analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 7-day rolling windows with daily boundary precision, ensuring each day represents unique users active within the preceding 7-day period
- **Final calculation**: The final `user_wau` value represents the count of unique addresses that interacted with Allbridge bridge contracts on any day within the 7-day window ending on the specified timestamp, calculated using HyperLogLog merge operations for computational efficiency and accuracy

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

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

Allbridge Core

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown