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 Supply-side fees Methodology

## 1. Overview

deBridge Messaging supply-side fees represent the portion of cross-chain transfer fees that accrue to supply-side participants (such as liquidity providers or validators) rather than the protocol treasury. For deBridge Messaging, this metric is always zero because all fees collected from cross-chain transfers accrue directly to the deBridge Messaging treasury, with no revenue sharing to external participants.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Cross-chain transfer events**: Parsed `DeBridgeGate_Sent_event` logs from Ethereum, Arbitrum, Base, BSC, Avalanche, Fantom, Optimism, and Polygon networks
- **Asset mapping events**: Parsed `DeBridgeGate_PairAdded_event` logs from all supported chains to map deBridge Messaging internal asset IDs to token addresses
- **Token metadata**: Token decimal places and symbols for proper amount calculations
- **End-of-day price feeds**: Token prices in USD for currency conversion

## 3. Step-by-step calculation

### Component A: Asset ID mapping
- **Purpose**: Creates a mapping between deBridge Messaging internal asset IDs and actual token addresses across different chains
- **Logic**: Parses `DeBridgeGate_PairAdded_event` logs from all supported chains to extract `debridgeId`, `nativeChainId`, and `nativeAddress` fields. Maps chain IDs to chain names (e.g., chain ID 1 to Ethereum, 42161 to Arbitrum) and removes duplicates to create a clean lookup table
- **Key fields**: `debridge_id` (internal asset identifier), `native_token_chain` (source blockchain), `native_token_address` (token contract address), `transaction_chain` (chain where mapping event occurred)

### Component B: Transfer fee extraction  
- **Purpose**: Extracts both flat and percentage-based fees from cross-chain transfer transactions
- **Logic**: Parses `DeBridgeGate_Sent_event` logs across eight supported chains. Extracts two fee types from the `feeParams` structure: `fixFee` (flat fee in native token) and `transferFee` (percentage-based fee in transferred token). Joins with asset mapping to resolve token addresses and determine the native chain for each transferred asset
- **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 address), `transfer_fee_token_address` (transferred token address)

### Component C: Flat fee processing
- **Purpose**: Processes fixed fees that are always denominated in the blockchain's native token
- **Logic**: Aggregates flat fees to daily level, applies decimal corrections based on native token specifications, and converts to USD using end-of-day price feeds. Uses wrapped native token addresses for each chain (e.g., WETH for Ethereum, WMATIC for Polygon)
- **Key fields**: `amount` (decimal-corrected fee amount), `token_address` (wrapped native token), `timestamp` (daily aggregation boundary)

### Component D: Percentage fee processing  
- **Purpose**: Processes variable fees that are denominated in the token being transferred
- **Logic**: Aggregates percentage-based fees to daily level, applies decimal corrections based on the specific token's decimal places, and converts to USD using end-of-day price feeds. Each fee is denominated in the actual token being transferred across chains
- **Key fields**: `amount` (decimal-corrected fee amount), `token_address` (transferred token address), `token_symbol` (token identifier)

### Final aggregation
- **Combining components**: Unions flat fees and percentage fees into a single fee stream, maintaining separate records for each fee type while preserving token-specific information
- **Currency conversion**: All fees are converted to USD using end-of-day token prices, with decimal corrections applied before conversion to ensure accurate amounts
- **Time aggregation**: Fees are aggregated to daily boundaries using timestamp truncation to the day level
- **Final calculation**: Since deBridge Messaging retains all collected fees in its treasury without sharing revenue with external participants, supply-side fees are set to zero for all records. The total fees are calculated but supply-side fees always equal 0% of total fees

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

Portion of fees distributed to service providers or supply-side participants.

deBridgeDBR

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown