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

## 1. Overview

The Across Monthly Active Users (MAU) metric measures the number of unique users who completed bridge transactions through the Across protocol over rolling 30-day periods. This metric answers the business question: "How many distinct users are actively using Across cross-chain bridge services each month?" The calculation uses HyperLogLog algorithms to efficiently estimate cardinality across large datasets and creates multiple dimensional breakdowns for analysis at different granularity levels.

## 2. Data sources

The metric relies on the following raw data sources:
- **Across protocol smart contract events**: Parsed `FilledRelay` and `FilledV3Relay` events from Across v2 and v2.5 SpokePool contracts across multiple blockchains including Ethereum, Arbitrum, Base, BSC, Linea, Optimism, Polygon, Scroll, Worldchain, and zkSync Era
- **Across v1 protocol events**: Parsed `DepositRelayed` events from the legacy BridgePoolProd contract on Ethereum
- **Blockchain transaction data**: Transaction timestamps and hashes from all supported chains for temporal ordering and deduplication
- **Cross-chain bridge completion records**: Events that capture successful bridge transaction fulfillment, containing recipient address information

## 3. Step-by-step calculation

### Component A: User identification from bridge events
- **Purpose**: Extract unique user addresses from completed cross-chain bridge transactions across all Across protocol versions and chains
- **Logic**: The system processes various Across protocol smart contract events that indicate successful bridge completions. For most events, it extracts the `recipient` field directly. For newer v2.5 `FilledV3Relay` events, it extracts the recipient from the nested `relayExecutionInfo.updatedRecipient` field. For legacy v1 events, it uses `depositData.l1Recipient`. All identified users are classified as 'Trader' type since they represent bridge transaction recipients. The system processes events from 10+ blockchain networks including Ethereum, Arbitrum, Base, BSC, Linea, Optimism, Polygon, Scroll, Worldchain, and zkSync Era.
- **Key fields**: `block_timestamp` for temporal ordering, `transaction_hash` for deduplication, `recipient` or `updatedRecipient` for user identification, and chain-specific contract addresses

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily unique user counts by deduplicating user addresses within each day, chain, and user type combination
- **Logic**: The system truncates blockchain timestamps to daily boundaries and creates distinct combinations of user addresses, chains, and user types for each day. This eliminates duplicate counting when the same user performs multiple bridge transactions on the same day. The aggregation preserves dimensional attributes like chain identifiers and user types for later breakdown analysis. All transactions are categorized under the 'bridges' market sector and 'mint_and_burn' business segment.
- **Key fields**: `timestamp` (daily truncated), `chain`, `user_type`, `user_address`, `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into HyperLogLog sketches for efficient cardinality estimation in rolling window calculations
- **Logic**: For each day's unique user set, the system creates HyperLogLog sketches using 15-bit precision. This probabilistic data structure enables efficient merging of user sets across multiple days without storing individual user addresses. The sketches maintain separate dimensions for chain, user type, and product identifiers to support various aggregation levels.
- **Key fields**: `hll` sketches containing encoded user sets, dimensional attributes for grouping

### Component D: Datespine and rolling window creation
- **Purpose**: Create a complete temporal framework with 30-day rolling windows for consistent MAU calculation across all time periods
- **Logic**: The system generates a complete datespine covering all days from the earliest available data to yesterday, ensuring no gaps in the time series. For each day in the datespine, it creates a 30-day rolling window by generating timestamps for the current day plus the previous 29 days. This approach ensures that MAU calculations include exactly 30 days of data even when some intermediate days have no bridge activity. The datespine joins with daily HLL sketches to populate the rolling windows with actual user data where available.
- **Key fields**: `timestamp` for window end dates, `joinday` for window member dates, temporal range parameters

### Component E: Rolling window HLL aggregation
- **Purpose**: Merge HyperLogLog sketches across 30-day windows to calculate unique user counts over monthly periods
- **Logic**: For each day's 30-day window, the system merges all available HLL sketches using `hll_count.merge_partial()`. This operation combines the probabilistic user sets while maintaining cardinality accuracy. The merging happens separately for each dimensional combination (chain, user type, product) to support multiple aggregation levels. Missing days in the window are handled gracefully since HLL merge operations can work with partial data.
- **Key fields**: Merged `hll` sketches representing 30-day user sets, dimensional grouping attributes

### Component F: Dimensional breakdown creation
- **Purpose**: Generate multiple aggregation views of MAU data for different analysis perspectives
- **Logic**: The system creates four distinct dimensional breakdowns from the merged HLL sketches. The project-level view aggregates across all dimensions by setting chain, product, and user type to null. The chain-level view groups by individual chains while nullifying other dimensions. The user type view maintains user type groupings. The product view groups by product identifiers. Each breakdown extracts the final cardinality estimate using `hll_count.extract()` to convert sketches back to integer user counts.
- **Key fields**: `dimensions` indicating breakdown type, dimensional attributes (nullified as appropriate), `user_mau` containing final counts

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset supporting multiple aggregation levels
- **Time aggregation**: The metric uses rolling 30-day windows calculated daily, with monthly partitioning for efficient storage and querying
- **Final calculation**: The final MAU value represents the estimated number of unique users who completed at least one bridge transaction within any 30-day period ending on the specified date, calculated using HyperLogLog cardinality estimation with 15-bit precision for approximately 1% accuracy

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

Unique revenue-generating users over a rolling 30-day window.

AcrossACX

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown