Allbridge Core allows users to send stablecoins from one chain to another almost immediately by using native liquidity pools deployed across 5 EVM and non-EVM blockchains. Liquidity providers receive the majority of transfer fees paid by users (supply-side fees).

Allbridge Core is a cross-chain stablecoin bridge. Allbridge Core was co-founded by Yuriy Savchenko and Andriy Velykyy, and was launched in September 2022.

The Allbridge team own and govern the protocol. They currently take a cut of the transfer fees paid by the users (revenue). Allbridge Core’s investors include Race Capital and others.

github

twitter

discord

website

Bridges

Allbridge Core

# Allbridge Core Transfer volume Methodology

## 1. Overview

Allbridge transfer volume measures the daily USD value of assets transferred through the Allbridge cross-chain bridge protocol. This metric captures the total volume of tokens moved between supported blockchains (Ethereum, BSC, Polygon, Tron, and Solana) via Allbridge's bridge contracts. The calculation aggregates transfer amounts from bridge events across multiple chains and converts them to USD using end-of-day price feeds.

## 2. Data sources

The methodology relies on the following raw data sources:

- **Blockchain events**: Parsed `TokensSent` and `TokensReceived` events from Allbridge Bridge and Bridge2 contracts deployed on BSC, Ethereum, and Polygon
- **External data**: End-of-day token price feeds for USD conversion and token metadata for decimal precision handling
- **Chain mapping**: Static configuration mapping numeric chain identifiers to blockchain names (1=Ethereum, 2=BSC, 3=Tron, 4=Solana, 5=Polygon)

## 3. Step-by-step calculation

### Component A: Sent transfer extraction
- **Purpose**: Captures outgoing bridge transfers from BSC, Ethereum, and Polygon chains
- **Logic**: Extracts data from `TokensSent` events from both Bridge and Bridge2 contracts. Each event contains the destination chain ID, token address (extracted from hex-encoded `receiveToken` field), and transfer amount. The token address is normalized by taking the rightmost 40 characters and prefixing with '0x'. For transfers destined to Tron or Solana, the system maps the token address to Ethereum USDC since price feeds for those destination tokens may not be available. Transfer amounts are divided by 1000 to correct for the event's 3-decimal precision encoding.
- **Key fields**: `block_timestamp`, `transaction_hash`, `receiveToken` (converted to `token_address`), `destinationChainId`, `amount` (becomes `transfer_amount`)

### Component B: Received transfer extraction  
- **Purpose**: Captures incoming bridge transfers specifically from Tron and Solana to avoid double counting
- **Logic**: Extracts data from `TokensReceived` events on BSC, Ethereum, and Polygon, but only processes transfers that originated from Tron (chain ID 3) or Solana (chain ID 4). The origin chain ID is decoded from the first two bytes of the message field. Token addresses are hardcoded based on the destination chain: BUSD address for BSC, USDC addresses for Ethereum and Polygon. This selective processing prevents double counting since sent transfers already capture most bridge activity, but received events are needed to track volume from chains where direct event access is limited.
- **Key fields**: `block_timestamp`, `transaction_hash`, `message` (contains encoded origin chain ID), `amount` (becomes `transfer_amount`)

### Component C: Decimal correction and chain mapping
- **Purpose**: Normalizes transfer amounts and maps chain identifiers to readable names  
- **Logic**: For sent transfers, amounts are already divided by 1000 during extraction. For received transfers, standard decimal correction is applied using token metadata to ensure proper decimal precision. Chain IDs are mapped to chain names using the static configuration. The destination chain determines which blockchain's price feeds will be used for USD conversion.
- **Key fields**: `transfer_amount` (decimal-corrected), `chain` (mapped from chain ID), `token_address`

### Component D: Transfer union and deduplication
- **Purpose**: Combines sent and received transfers while preventing double counting
- **Logic**: Unions the processed sent transfers with the filtered received transfers (only from Tron/Solana origins). This approach ensures complete coverage of bridge volume while avoiding duplication, since most transfer activity is captured through sent events, and received events only supplement with transfers from chains where sent events aren't directly accessible.
- **Key fields**: All transfer fields unified into single dataset with `origin_chain`, `destination_chain`, `chain`, `token_address`, `transfer_amount`

### Final aggregation
- **Combining components**: Transfer data is grouped by day, chain, and token address, with transfer amounts summed to calculate daily volume per token per chain
- **Currency conversion**: USD conversion is performed using end-of-day price feeds matched to the chain and token address, with decimal correction disabled since amounts are already normalized  
- **Time aggregation**: Daily boundaries are created using timestamp truncation to day level, with timezone handling ensuring consistent daily cutoffs
- **Final calculation**: The metric value represents the sum of all bridge transfer amounts in USD for each day, chain, and token combination, with a fill-zeros strategy applied to ensure no gaps in the daily time series and chain availability filtering to respect data availability windows

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

Total value of assets moved across chains through a bridge.

Allbridge Core

Transfer volume

Transfer volume

Competitive landscape

Chain breakdown