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 Transaction count Methodology

## 1. Overview

The deBridge Messaging transaction count metric measures the daily number of unique cross-chain transfer transactions processed through the deBridge Messaging interoperability protocol. This metric counts distinct transaction hashes that initiated transfers via DeBridgeGate contracts across supported blockchain networks, providing visibility into the protocol's cross-chain bridging activity and user adoption.

## 2. Data sources

- **Smart contract events**: Parsed `Sent` events from DeBridgeGate contracts deployed on Ethereum, Arbitrum, Base, BSC, Avalanche, Fantom, Optimism, and Polygon networks
- **Asset configuration events**: Parsed `PairAdded` events from the same DeBridgeGate contracts that establish mappings between deBridge Messaging asset IDs and their native token addresses
- **Chain metadata**: Hardcoded chain ID to chain name mappings for the 8 supported networks
- **Chain availability configuration**: Internal configuration data that determines which chains should be included in the final metric output

## 3. Step-by-step calculation

### Component A: Asset mapping dimension
- **Purpose**: Creates a reference table mapping deBridge Messaging asset identifiers to their corresponding native tokens and chains
- **Logic**: Processes `PairAdded` events from DeBridgeGate contracts across all 8 supported chains. Extracts the `debridgeId`, `nativeChainId`, and `nativeAddress` fields from each event. Maps numeric chain IDs (like "1" for Ethereum, "42161" for Arbitrum) to human-readable chain names using hardcoded mappings. Removes duplicate entries and filters out any records with null chain mappings to ensure clean reference data.
- **Key fields**: `transaction_chain` (where the event occurred), `debridge_id` (unique asset identifier), `native_token_chain` (origin blockchain), `native_token_address` (token contract address)

### Component B: Transfer event extraction  
- **Purpose**: Captures all cross-chain transfer initiation events from deBridge Messaging protocol contracts
- **Logic**: Extracts `Sent` events from DeBridgeGate contracts deployed on Ethereum, Arbitrum, Base, BSC, Avalanche, Fantom, Optimism, and Polygon. Each event represents a user initiating a cross-chain transfer. Joins with the asset mapping dimension to enrich transfer records with native token information. Preserves transaction metadata including block timestamp, transaction hash, and log index for proper event identification. Assigns business classification fields marking all transfers as interoperability sector transactions.
- **Key fields**: `block_timestamp` (when transfer occurred), `transaction_hash` (unique transaction identifier), `debridge_id` (asset being transferred), `real_chain` (source chain), `token_address` (native token contract), `volume_amount` (transfer amount)

### Final aggregation
- **Combining components**: Uses the enriched transfer data from Component B, which already incorporates the asset mapping logic from Component A through the join operation
- **Time aggregation**: Groups transfer events by day using timestamp truncation on the `block_timestamp` field, creating daily boundary aggregations
- **Transaction counting**: Counts distinct `transaction_hash` values within each day and chain combination to avoid double-counting transactions that may have multiple associated events
- **Gap filling**: Applies the finalize metric macro to ensure complete daily time series with zero values for days with no transactions, validates the data schema, and handles any missing date ranges
- **Chain filtering**: Applies chain availability filtering to ensure only currently supported chains are included in the final metric output, allowing for dynamic chain support management
- **Final calculation**: The final metric value represents the total number of unique transactions per day per chain that initiated cross-chain transfers through the deBridge Messaging protocol

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

Confirmed transactions added to the blockchain.

deBridgeDBR

Transaction count

Transaction count

Competitive landscape

Chain breakdown