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 Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average amount of fees collected from users per day on the deBridge Messaging protocol. This metric answers the business question: "How much revenue does deBridge Messaging generate per active user?" The calculation divides total daily fees by the number of daily active users, providing insight into user monetization efficiency across the cross-chain bridge protocol.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Blockchain events**: Parsed `DeBridgeGate_Sent` events from Ethereum, Arbitrum, Avalanche, Base, BSC, Fantom, Optimism, and Polygon networks, containing user addresses and fee information
- **Asset mapping events**: Parsed `DeBridgeGate_PairAdded` events from all supported chains to map deBridge Messaging asset IDs to native token addresses
- **Token data**: Token metadata including decimal places and symbol information for proper amount normalization
- **External data**: End-of-day price feeds for USD conversion of fees collected in various tokens
- **Chain availability data**: Information about data availability periods for each blockchain network

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identifies daily active users across all supported chains
- **Logic**: Extracts user addresses from parsed `DeBridgeGate_Sent` events across eight blockchains (Ethereum, Arbitrum, Avalanche, Base, BSC, Fantom, Optimism, Polygon). The `nativeSender` field from each `Sent` event identifies the user initiating a cross-chain transfer. Timestamps are truncated to daily granularity to group users by day.
- **Key fields**: `nativeSender` (user address), `block_timestamp` (transaction timing), `chain` (source blockchain)

### Component B: User aggregation with HyperLogLog
- **Purpose**: Creates accurate daily unique user counts across multiple dimensions
- **Logic**: Aggregates unique users per day using HyperLogLog algorithm for memory-efficient counting. Creates breakdowns by different dimensions including overall project level, individual chains, user types, and product IDs. Applies chain availability filtering to ensure accurate reporting only for periods when each chain's data is available.
- **Key fields**: `user_dau` (unique user count), `dimensions` (aggregation level), `chain_id` (specific blockchain)

### Component C: Asset ID mapping
- **Purpose**: Maps deBridge Messaging internal asset IDs to actual token addresses
- **Logic**: Processes `DeBridgeGate_PairAdded` events to create a lookup table connecting deBridge Messaging asset IDs with their corresponding native token addresses and chain information. Maps numeric chain IDs to chain names (e.g., '1' becomes 'ethereum', '42161' becomes 'arbitrum'). Removes duplicates and null values to create a clean mapping table.
- **Key fields**: `debridgeId` (internal asset identifier), `nativeChainId` (numeric chain ID), `nativeAddress` (token contract address)

### Component D: Fee extraction from transfer events
- **Purpose**: Extracts both types of fees collected by deBridge Messaging protocol
- **Logic**: Processes the same `DeBridgeGate_Sent` events to extract fee information from the `feeParams` structure. Captures two distinct fee types: `fixFee` (flat fee denominated in the source blockchain's native token) and `transferFee` (percentage-based fee denominated in the token being transferred). Joins with the asset mapping to resolve token addresses for proper fee processing.
- **Key fields**: `fixFee` (flat fee amount), `transferFee` (percentage fee amount), `feeParams` (fee structure)

### Component E: Fixed fee processing
- **Purpose**: Normalizes and converts flat fees to USD
- **Logic**: Processes fixed fees which are always denominated in the native token of the source blockchain (e.g., ETH for Ethereum, MATIC for Polygon). Applies decimal correction using token metadata to normalize amounts to proper decimal places. Converts amounts to USD using end-of-day price feeds, matching fees to the appropriate day's exchange rates.
- **Key fields**: `fixed_fee_amount` (normalized fee), `fixed_fee_token_address` (native token address), `amount` (USD-converted value)

### Component F: Percentage fee processing
- **Purpose**: Normalizes and converts transfer fees to USD
- **Logic**: Processes percentage-based fees which are denominated in the token being transferred across chains. Uses the asset mapping to identify the correct token address for each transfer. Applies decimal correction based on the specific token's decimal configuration. Converts to USD using end-of-day price feeds specific to each token type.
- **Key fields**: `transfer_fee_amount` (normalized fee), `transfer_fee_token_address` (transferred token address), `amount` (USD-converted value)

### Final aggregation
- **Combining components**: Fixed fees and percentage fees are combined using union operations to create a unified fee dataset, with both fee types contributing to total daily fees across all chains
- **Currency conversion**: All fees are converted to USD using end-of-day price feeds, ensuring consistent valuation regardless of the original fee token denomination
- **Time aggregation**: Fees and users are both aggregated to daily granularity using timestamp truncation to day level, ensuring alignment between numerator and denominator
- **Final calculation**: AFPU is calculated by dividing the sum of all daily fees (fixed fees + percentage fees across all chains and tokens) by the count of daily active users (unique addresses that initiated transfers). The calculation applies gap-filling with zeros for days with missing data to maintain continuous time series reporting

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

deBridgeDBR

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape