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 Active users (daily) Methodology

## 1. Overview

The Axelar daily active users (DAU) metric measures the number of unique users interacting with the Axelar protocol each day across multiple blockchain networks. This metric captures users who initiate cross-chain transactions, including General Message Passing (GMP) calls, cross-chain token transfers, and interoperability operations. The calculation uses HyperLogLog (HLL) approximation for efficient distinct counting across multiple dimensional breakdowns while maintaining accuracy for large-scale data aggregation.

## 2. Data sources

The calculation relies on several types of blockchain data:
- **Axelar Gateway contract events**: Parsed smart contract events from Axelar Gateway contracts deployed on 9 EVM chains (Ethereum, Arbitrum, Avalanche, Base, BSC, Celo, Fantom, Optimism, Polygon), including `ContractCall`, `ContractCallWithToken`, `TokenSent`, and `Executed` events
- **Token transfer events**: ERC-20 token transfer events from supported EVM chains that correspond to Axelar protocol interactions
- **Transaction records**: Base transaction data from EVM chains containing sender addresses and transaction metadata
- **Token metadata**: Token information including symbols, decimals, and contract addresses for proper token identification across chains
- **Chain mapping data**: Standardized chain name mappings to normalize chain identifiers across different data sources

## 3. Step-by-step calculation

### Component A: GMP messaging transactions
- **Purpose**: Captures users who initiate Axelar General Message Passing transactions for cross-chain communication
- **Logic**: Processes two types of Gateway contract events across all supported chains. For `ContractCallWithToken` events, extracts the token symbol and amount directly from the event parameters. For `ContractCall` events (without tokens), joins with corresponding token transfer events to capture any associated token movements, using log index proximity to match related events. Extracts user addresses from transaction sender fields and filters out zero-value transfers. All interactions are classified under the 'Interoperability' business line and 'axelarnetworkv1' product identifier
- **Key fields**: `user_address` (transaction sender), `block_timestamp` (for daily aggregation), `chain` (source blockchain), `amount` and `symbol` (for token transfers)

### Component B: Destination chain transfers  
- **Purpose**: Identifies users whose cross-chain transfers are successfully executed on destination blockchains
- **Logic**: Monitors `Executed` events emitted by Axelar Gateway contracts on destination chains, indicating successful completion of cross-chain transfers. Joins these events with token transfer records using transaction hash and sequential log index matching (executed event occurs immediately after the transfer). Links with transaction data to extract the original user address who initiated the cross-chain operation. Only includes transfers with positive amounts and maintains chain-level granularity for tracking
- **Key fields**: `user_address` (original transaction sender), `token_address` and `amount` (transferred asset details), `chain` (destination blockchain)

### Component C: Source chain transfers
- **Purpose**: Captures users who initiate outbound cross-chain transfers from source blockchains  
- **Logic**: Processes `TokenSent` events from Gateway contracts representing the initiation of cross-chain token transfers. Applies exclusion logic to avoid double-counting by filtering out transfers where the destination chain is also an EVM chain tracked by Token Terminal (these would be captured by destination chain transfers instead). Joins with token transfer events and transaction records using the same log index proximity matching. Extracts destination chain information to understand cross-chain flow patterns
- **Key fields**: `user_address` (transaction initiator), `destination_chain` (target blockchain), `amount` and `token_address` (transfer details), `chain` (source blockchain)

### Component D: User aggregation and deduplication
- **Purpose**: Combines all user interactions and creates daily distinct user counts
- **Logic**: Unions all users from the three interaction types (GMP messaging, destination transfers, source transfers) and truncates timestamps to daily boundaries. Applies distinct logic to ensure each user address is counted only once per day per chain, regardless of how many transactions they performed. Classifies all users as 'Sender' type since the metric focuses on transaction initiators. Groups by day, chain, user type, and product identifiers
- **Key fields**: `timestamp` (daily boundary), `user_dau` (distinct user address), `chain`, `product_id`

### Final aggregation
- **Combining components**: The daily user data is processed through HyperLogLog initialization to enable efficient approximate distinct counting across multiple dimensional breakdowns
- **Dimensional breakdowns**: Creates separate aggregations by project level (all chains combined), individual chain, user type, and product identifier, using HLL merge operations to maintain distinct count accuracy
- **Schema standardization**: Applies the `finalize_metric_user_dau` macro to ensure consistent output format, including proper data type casting, null handling for unused dimension fields, and zero-filling for missing days
- **Final calculation**: Each dimensional breakdown extracts the final distinct user count using `hll_count.extract()` function, providing approximate but highly accurate daily active user counts that can be efficiently queried and aggregated across different time periods and dimensions

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

Unique revenue-generating users over a fixed 24-hour window.

Axelar NetworkAXL

Archived

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown