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 Revenue Methodology

## 1. Overview

deBridge Messaging revenue represents the total fees collected by the deBridge Messaging protocol from cross-chain bridge transfers. The metric captures 100% of fees as revenue since all fees accrue directly to the deBridge Messaging treasury. The calculation combines two types of fees: flat fees charged in native tokens and percentage-based fees charged in the tokens being transferred. Revenue is calculated daily in USD across all supported blockchain networks.

## 2. Data sources

- **Asset mapping events**: Parsed `DeBridgeGate_PairAdded` events from Ethereum, Arbitrum, Avalanche, Base, BSC, Fantom, Optimism, and Polygon providing mappings between deBridge Messaging asset IDs and native token addresses
- **Transfer events**: Parsed `DeBridgeGate_Sent` events from Ethereum, Arbitrum, Avalanche, Base, BSC, Fantom, Optimism, and Polygon containing fee parameters for cross-chain transfers
- **Token metadata**: Token decimals, symbols, and contract information for proper normalization
- **End-of-day price feeds**: USD price data for converting all fee amounts to consistent currency
- **Wrapped native token addresses**: Hardcoded addresses for wrapped native tokens on each supported chain (WETH, WMATIC, WBNB, etc.)

## 3. Step-by-step calculation

### Component A: Asset mapping initialization
- **Purpose**: Creates mappings between deBridge Messaging asset IDs and their corresponding native token addresses across different blockchain networks
- **Logic**: Extract `debridgeId`, `nativeChainId`, and `nativeAddress` fields from `DeBridgeGate_PairAdded` events across all supported chains. Map numeric chain IDs to chain names using predefined mappings (1 for Ethereum, 42161 for Arbitrum, etc.). Remove duplicates and null values to create clean asset mapping table
- **Key fields**: `transaction_chain` (where event occurred), `debridge_id` (unique asset identifier), `native_token_chain` (original chain of token), `native_token_address` (token contract address)

### Component B: Transfer fee extraction
- **Purpose**: Extracts fee data from cross-chain transfer events, identifying both flat fees and percentage-based fees
- **Logic**: Parse `DeBridgeGate_Sent` events from all supported chains to extract fee parameters from nested `feeParams` structure. Extract `fixFee` amounts (flat fees charged in native tokens) and `transferFee` amounts (percentage-based fees charged in transferred tokens). Join with asset mapping data to resolve proper token addresses for percentage-based fees. Add metadata including business line classification as 'Interoperability'
- **Key fields**: `fixed_fee_amount` (flat fee in native tokens), `transfer_fee_amount` (percentage fee in transferred tokens), `fixed_fee_token_address` (wrapped native token), `transfer_fee_token_address` (actual transferred token)

### Component C: Flat fee processing
- **Purpose**: Processes flat fees that are always charged in the native token of each blockchain
- **Logic**: Filter for fixed fee amounts from transfer events. Use hardcoded wrapped native token addresses for each chain (WETH for Ethereum, WMATIC for Polygon, etc.) as the fee token. Truncate timestamps to daily boundaries. Apply decimal correction using token metadata to normalize amounts to standard decimal places. Convert all amounts to USD using end-of-day price feeds
- **Key fields**: `amount` (decimal-corrected fee amount), `token_address` (wrapped native token address), `timestamp` (daily boundary)

### Component D: Percentage fee processing  
- **Purpose**: Processes percentage-based fees that are charged in the same token being transferred
- **Logic**: Filter for transfer fee amounts from transfer events. Use the actual transferred token addresses (resolved through asset mapping) as the fee token. Truncate timestamps to daily boundaries. Apply decimal correction using token metadata for each specific token being transferred. Convert all amounts to USD using end-of-day price feeds matching the specific tokens
- **Key fields**: `amount` (decimal-corrected fee amount), `token_address` (transferred token address), `timestamp` (daily boundary)

### Final aggregation
- **Combining components**: Union flat fees and percentage-based fees into a single dataset, maintaining all dimensional attributes (chain, account, token details)
- **Currency conversion**: All fee amounts converted to USD using end-of-day price feeds matched to specific token contracts and daily timestamps
- **Time aggregation**: Aggregate all fees by daily boundaries, applying fill-zeros strategy to ensure complete time series without gaps
- **Final calculation**: Sum all USD-denominated fees by day and chain. Apply 100% fee-to-revenue conversion since deBridge Messaging protocol retains all collected fees as treasury revenue. Apply chain availability filters to ensure data quality and completeness across all supported networks

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

deBridgeDBR

Revenue

Revenue

Competitive landscape

Chain breakdown