Axelar Network node operators validate cross-chain transactions. They currently take a cut of transfer fees (supply-side fees).

Axelar Network is an interoperability protocol that allows for decentralized transfers of data and assets between blockchains. Axelar Network was founded by Sergey Gorbunov and Georgios Vlachos, and was launched in 2022. This dashboard currently only includes data for the following chains: Arbitrum, Avalanche, Base, BNB Chain, Celo, Ethereum, Fantom, Optimism, and Polygon.

AXL tokenholders own and govern the protocol. They currently take a cut of transfer fees paid by transfer senders (revenue). Axelar Network’s investors include Polychain Capital, Dragonfly Capital, North Island Ventures, etc.

github

twitter

discord

etherscan

website

Interoperability

Axelar Network

# Axelar Network Revenue Methodology

## 1. Overview

Axelar revenue represents the protocol's earnings from its cross-chain interoperability services. Currently, Axelar generates zero revenue despite collecting fees from users. The protocol charges 0.2 AXL tokens per General Message Passing (GMP) transaction but does not retain these fees as revenue, likely distributing them entirely to validators and network participants.

## 2. Data sources

The methodology relies on several key data sources:
- **Axelar Gateway contract events**: Parsed `Gateway_Executed`, `Gateway_TokenSent`, `Gateway_ContractCallWithToken`, and `Gateway_ContractCall` events from Axelar v1 contracts deployed across 9 EVM chains
- **Token transfer events**: ERC-20 token transfer logs from Ethereum, Arbitrum, Avalanche, BSC, Base, Celo, Fantom, Optimism, and Polygon
- **Transaction data**: Complete transaction records from the 9 supported EVM chains to identify users and transaction contexts
- **End-of-day price feeds**: AXL token price data for USD conversion
- **Token metadata**: Token symbol and decimal information for proper amount calculations

## 3. Step-by-step calculation

### Component A: Transaction activity tracking
- **Purpose**: Identify and count all Axelar cross-chain transactions across three activity types
- **Logic**: The system tracks three distinct types of cross-chain activities. First, GMP messaging transactions are captured by parsing `Gateway_ContractCallWithToken` and `Gateway_ContractCall` events from Axelar Gateway contracts. For token-enabled calls, the `amount` and `symbol` are extracted directly from the event. For calls without tokens, the system joins with token transfer events occurring in the same transaction to capture transferred amounts and resolves token symbols through metadata lookups. Second, destination chain transfers are identified through `Gateway_Executed` events joined with corresponding token transfers, capturing tokens received on destination chains. Third, source chain transfers use `Gateway_TokenSent` events joined with token transfers to track tokens sent from origin chains, with filtering to exclude transfers to EVM chains that are already tracked via destination events to prevent double-counting
- **Key fields**: `transaction_hash` for transaction identification, `block_timestamp` for daily aggregation, `chain` for chain-specific tracking, `user_address` from transaction sender, `amount` and `symbol` for transfer values

### Component B: Transaction count aggregation
- **Purpose**: Aggregate distinct transaction counts by day across all chains and activity types
- **Logic**: Daily transaction counts are calculated by truncating `block_timestamp` to day boundaries and using approximate distinct counts of `transaction_hash` values. Each of the three activity types (GMP messaging, destination transfers, source transfers) is aggregated separately and then combined using union operations. The aggregation groups by timestamp, chain, and business classification fields while maintaining separate counts for each activity type
- **Key fields**: `timestamp` truncated to daily boundaries, `chain_id` for per-chain tracking, `transaction_count` as approximate distinct transaction hashes

### Component C: Fee calculation
- **Purpose**: Calculate theoretical fees collected based on transaction volumes
- **Logic**: A fixed fee structure applies 0.2 AXL tokens per GMP transaction. The total daily transaction count is multiplied by 0.1 as a scaling factor to avoid double-counting across the three activity types, then multiplied by 0.2 to represent the per-transaction fee. The fee calculation uses the AXL token contract address on Ethereum as the reference token. All calculations maintain the daily timestamp grain and chain-level granularity from the transaction count data
- **Key fields**: `transaction_count` multiplied by scaling factors, `token_address` set to AXL contract address, `fees` as the calculated AXL amount

### Component D: USD conversion
- **Purpose**: Convert AXL token fees to USD values using market prices
- **Logic**: The calculated AXL fee amounts are converted to USD using end-of-day token price feeds. The conversion process joins fee calculations with price data based on the AXL token address and transaction timestamp. Standard decimal correction is applied to ensure proper token amount representation before price multiplication. The conversion maintains all dimensional attributes including timestamp grain and chain identification
- **Key fields**: `fees` converted from AXL to USD amounts, `timestamp` for price feed joining

### Final aggregation
- **Combining components**: The fee calculation in USD serves as the intermediate step, but the final revenue calculation explicitly sets all revenue values to zero regardless of calculated fees
- **Currency conversion**: AXL token fees are converted to USD using end-of-day price feeds and standard decimal corrections for the AXL token
- **Time aggregation**: Data is aggregated at daily boundaries using timestamp truncation, with consistent daily grain maintained throughout the calculation
- **Final calculation**: Despite collecting fees that could theoretically generate revenue, the methodology explicitly sets `revenue` to 0 for all records, indicating that Axelar operates as a zero-revenue protocol where all collected fees are distributed to network participants rather than retained as protocol revenue

*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.

Axelar NetworkAXL

Archived

Revenue

Revenue

Competitive landscape

Chain breakdown