deBridge operates two main products: (1) deBridge Messaging - node operators validate cross-chain transactions for data and asset transfers, and (2) DLN (deBridge Liquidity Network) - an order book of cross-chain intents where Makers create intents in the source chain and Takers provide liquidity on the destination chain. Validators currently do not take a cut of transfer fees (supply-side fees).

deBridge is an interoperability protocol with two products: deBridge Messaging enables decentralized transfers of data and assets between blockchains, and DLN (deBridge Liquidity Network) is a cross-chain token bridge and trading infrastructure. deBridge was founded by Alex Smirnov and launched in 2021, with DLN launched in 2023.

The deBridge team and investors own and govern the protocol. They currently take all transfer fees paid by traders (revenue). deBridge's investors include ParaFi Capital, Animoca Brands, Huobi Ventures, Lemniscap, etc. All fees paid by traders are accumulated on smart contracts operated by the deBridge team and will be governed by deBridge token holders.

github

twitter

discord

website

Interoperability

deBridge

# deBridge Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who have initiated cross-chain bridge transactions through deBridge Messaging within any 7-day period. This metric helps assess user engagement and platform adoption across deBridge Messaging's multi-chain infrastructure. The calculation uses HyperLogLog probabilistic counting to efficiently aggregate unique users across rolling 7-day windows without double-counting users who are active on multiple days within the same week.

## 2. Data sources

- **Parsed smart contract events**: `DeBridgeGate_Sent_event` events from deBridge Messaging gateway contracts across eight blockchains (Arbitrum, Avalanche, Base, BSC, Ethereum, Fantom, Optimism, and Polygon)
- **Blockchain transaction data**: Block timestamps and transaction hashes from the respective blockchain networks
- **Chain configuration data**: Chain availability and filtering rules to ensure only supported chains are included in calculations

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify all users who have initiated cross-chain bridge transactions
- **Logic**: Parse `DeBridgeGate_Sent_event` events across all eight supported blockchains. Extract the `nativeSender` parameter from each event, which represents the wallet address of the user initiating the bridge transaction. Classify all users as 'Sender' type and assign them to the 'interoperability' market sector. Apply chain availability filtering to ensure only data from currently supported and active chains is included.
- **Key fields**: `nativeSender` (user wallet address), `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `chain` (source blockchain)

### Component B: Daily user aggregation  
- **Purpose**: Create daily unique user counts as the foundation for weekly calculations
- **Logic**: Group all user activity by day using timestamp truncation to daily granularity. For each day, identify distinct user addresses across all chains and dimensions (chain, user type, product). Create HyperLogLog sketches for each daily user set to enable efficient probabilistic counting in subsequent steps. Maintain dimensional breakdowns by chain, user type, market sector, business segment, and product.
- **Key fields**: `timestamp` (daily truncated), `user_address` (unique user identifier), `chain` (blockchain network), `user_type` (classification as Sender)

### Component C: Time series construction
- **Purpose**: Ensure complete time coverage for accurate rolling window calculations
- **Logic**: Generate a continuous datespine covering the full date range from the earliest user activity through the previous day. Create jointables that map each date to its corresponding 7-day lookback period (current day plus 6 previous days). This approach ensures that weekly calculations don't skip dates with no activity, which would create gaps in the rolling window logic.
- **Key fields**: `timestamp` (daily dates), `joinday` (individual days within each 7-day window)

### Component D: Weekly window construction
- **Purpose**: Build 7-day rolling windows for weekly active user calculation
- **Logic**: Join the datespine jointables with daily HyperLogLog sketches to create overlapping 7-day windows. For each target date, include all daily user activity from that date plus the 6 preceding days. This creates a rolling window where each day's WAU represents users active in the current 7-day period. Maintain all dimensional breakdowns during window construction.
- **Key fields**: `timestamp` (target date), `hll` (daily HyperLogLog sketch), dimensional fields (`chain_id`, `user_type`, `product_id`)

### Component E: Dimensional breakdowns
- **Purpose**: Calculate weekly active users across different analytical dimensions
- **Logic**: Create four separate aggregation views from the windowed data. First, aggregate at the overall project level by merging all HLL sketches regardless of chain, user type, or product. Second, break down by individual chains to show cross-chain usage patterns. Third, segment by user type to understand user behavior categories. Fourth, separate by product to analyze product-specific engagement. Each breakdown merges the appropriate HLL sketches and extracts the final unique user count.
- **Key fields**: `dimensions` (breakdown category), `chain_id` (for chain-level analysis), `user_type` (for user behavior analysis), `product_id` (for product analysis), `user_wau` (weekly active user count)

### Final aggregation
- **Combining components**: Union all dimensional breakdown results into a single comprehensive dataset that provides weekly active user counts across multiple analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundary logic with 7-day rolling windows, where each day represents users active in the current and previous 6 days
- **Final calculation**: Extract unique user counts from merged HyperLogLog sketches using `hll_count.extract(hll_count.merge_partial(hll))`, which provides probabilistic counts of distinct users across the 7-day windows while avoiding double-counting users who are active on multiple days within the same period

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

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

deBridgeDBR

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown