Across allows users to send tokens from one chain to another almost immediately without having to wait for the rollup’s challenge period. Liquidity providers provide liquidity and relayers handle the fills and in return they charge a transfer fee (supply-side fees).

Across is a cross-chain token bridge for L2s and rollups. Across was founded by Hart Lambur and launched in 2021.

ACX tokenholders own and govern the protocol. They currently don’t take a cut of the total transfer fees paid by the users (revenue). Across’ investors include Hack VC, Placeholder and Blockchain Capital.

governance

github

twitter

discord

etherscan

website

Bridges

Across

# Across Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average amount of fees paid per unique daily active user on the Across Protocol bridge. This metric is calculated by dividing total daily fees by the number of unique daily active users. The metric provides insight into user engagement value and fee monetization efficiency across the Across Protocol's multi-chain bridging infrastructure.

## 2. Data sources

- **Multi-chain bridge events**: Parsed `FilledRelay` event logs from Ethereum, Arbitrum, Optimism, Base, ZkSyncEra, Polygon, BSC, Gnosis, Linea, Scroll, and Worldchain across protocol versions v1, v2, v2.5, and v3
- **Legacy bridge events**: Ethereum `BridgePoolProd_DepositRelayed_event` logs from protocol v1
- **Token mapping events**: `HubPool_SetPoolRebalanceRoute_event` logs providing cross-chain token address mappings to L1 equivalents
- **Token metadata**: Token contract information including decimal precision and symbol data
- **External price data**: End-of-day token price feeds for USD conversion
- **Chain metadata**: Chain ID mappings for multi-chain transaction processing

## 3. Step-by-step calculation

### Component A: Daily active user identification
- **Purpose**: Identify unique users who completed bridge transactions each day
- **Logic**: Extract recipient addresses from `FilledRelay` events across all supported chains and protocol versions. For v1, use the `l1Recipient` field from `DepositRelayed` events. For v2/v2.5/v3, use the `recipient` field or `updatedRecipient` field from various `FilledRelay` events. All recipients are classified as 'Trader' type users in the 'bridges' market sector under 'mint_and_burn' business segment. Aggregate users by day using timestamp truncation to daily boundaries.
- **Key fields**: `recipient`, `updatedRecipient`, `l1Recipient`, `block_timestamp` for temporal grouping

### Component B: Daily active user aggregation
- **Purpose**: Count unique daily users efficiently across multiple dimensions
- **Logic**: Use HyperLogLog (HLL) data structure to count distinct users by day, chain, user type, and product dimensions. Create separate breakdowns for project-level totals, chain-level totals, user-type totals, and product-level totals. This enables efficient counting of unique users across large datasets while maintaining dimensional analysis capabilities.
- **Key fields**: `user_address` for HLL computation, `timestamp`, `chain`, `user_type`, `product_id` for dimensional grouping

### Component C: Protocol v1 and v2 fee calculation
- **Purpose**: Calculate bridge fees from earlier protocol versions using percentage-based fee structure
- **Logic**: For v1, extract `realizedLpFeePct`, `slowRelayFeePct`, and `instantRelayFeePct` from `DepositRelayed` events and apply these percentages to the `amount` field. For v2, extract `realizedLpFeePct` and `appliedRelayerFeePct` or `relayerFeePct` depending on contract version and apply to `fillAmount`. Sum LP fees and relayer fees for total bridge fees. Apply decimal correction using token metadata and convert to USD using end-of-day price feeds.
- **Key fields**: `realizedLpFeePct`, `relayerFeePct`, `amount`, `fillAmount`, `destinationToken`

### Component D: Protocol v2.5 and v3 fee calculation
- **Purpose**: Calculate bridge fees from newer protocol versions using input/output amount differential
- **Logic**: Extract `inputAmount` and `updatedOutputAmount` from `FilledV3Relay` and `FilledRelay` events across all supported chains. Map `inputToken` and `outputToken` addresses to their L1 equivalents using token mapping data from `HubPool_SetPoolRebalanceRoute_event`. Correct decimal precision using token metadata, then convert both input and output amounts to USD using end-of-day price feeds matched by L1 token address. Calculate fees as the USD difference between input and output amounts. Filter out invalid transactions and denied relayers to ensure data quality.
- **Key fields**: `inputAmount`, `updatedOutputAmount`, `inputToken`, `outputToken`, `originChainId`, `repaymentChainId`

### Component E: Token address mapping and normalization
- **Purpose**: Enable consistent fee calculation across different chains by mapping to L1 token equivalents
- **Logic**: Use `HubPool_SetPoolRebalanceRoute_event` to map chain-specific token addresses to their L1 Ethereum equivalents. This mapping enables consistent price lookups and decimal corrections regardless of which chain the token transaction occurred on. Extract `destinationChainId`, `destinationToken`, and `l1Token` fields to build comprehensive mapping tables.
- **Key fields**: `destinationChainId`, `destinationToken`, `l1Token` for cross-chain token identification

### Final aggregation
- **Combining components**: Union fees from v1/v2 calculations with v2.5/v3 calculations, grouping by day and origin chain. Sum all fee amounts for each day to get total daily fees across all protocol versions and chains.
- **Currency conversion**: Apply decimal correction using token metadata, then multiply by end-of-day USD prices matched by timestamp, token address, and chain. All fees are standardized to USD for consistent calculation.
- **Time aggregation**: Use daily timestamp boundaries (timestamp truncated to day) for both user counting and fee aggregation to ensure alignment between numerator and denominator.
- **Final calculation**: Divide total daily fees in USD by the count of unique daily active users using the `calculate_arpu` macro. Apply zero-filling strategy to handle days with missing data, ensuring continuous time series output.

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

AcrossACX

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape