Hop allows users to send tokens from one rollup to another almost immediately without having to wait for the rollup’s challenge period. Liquidity providers deposit funds into Hop AMM pools and receive trading fees from traders (supply-side fees).

Hop is a scalable rollup-to-rollup general token bridge. Hop was co-founded by Christopher Whinfrey and launched in 2021.

HOP tokenholders own and govern the protocol. They currently take a cut of the total transfer fees paid by users (revenue). Hop’s investors include 1confirmation, Infinite Capital, etc.

governance

github

twitter

discord

etherscan

website

Bridges

Hop Protocol

# Hop Protocol Active users (weekly) Methodology

## 1. Overview

The Weekly Active Users (WAU) metric measures the number of distinct users who interact with Hop protocol bridges within any 7-day rolling window. This metric provides insight into user engagement and adoption of Hop's cross-chain bridging services. The calculation uses HyperLogLog data structures to efficiently count distinct users across multiple time windows and dimensional breakdowns, ensuring accurate deduplication even when users are active on multiple chains or with multiple tokens.

## 2. Data sources

- **Blockchain events**: Parsed Hop protocol bridge contract events from Ethereum, Arbitrum, Optimism, Polygon, and Base blockchains
- **Bridge transaction logs**: `TransferSent` and `TransferSentToL2` events from L1Bridge and L2Bridge contracts 
- **Multi-token coverage**: Events from bridge contracts handling DAI, ETH, USDT, WBTC, HOP, MAGIC, RETH, SNX, SUSD, and MATIC tokens
- **Transaction metadata**: Blockchain transaction timestamps and transaction hashes for temporal ordering
- **Contract addresses**: Specific bridge contract addresses for each token and chain combination

## 3. Step-by-step calculation

### Component A: User identification from bridge events
- **Purpose**: Identifies unique users who interact with Hop protocol bridges across all supported chains and tokens
- **Logic**: Extracts user addresses from the `recipient` field of bridge transfer events. Scans `TransferSent` events from L2Bridge contracts on Arbitrum, Optimism, Polygon, and Base, as well as `TransferSentToL2` events from L1Bridge contracts on Ethereum. Covers multiple token bridges including DAI, ETH, USDT, WBTC, HOP, MAGIC, RETH, SNX, SUSD, and MATIC. Classifies all identified users as 'Trader' type within the 'bridges' market sector and 'mint_and_burn' business segment.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for transaction identification, `chain` for blockchain network, `recipient` for user address extraction, token-specific event parameters

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates identified users into daily distinct counts with dimensional breakdowns
- **Logic**: Groups bridge interaction events by day using timestamp truncation to daily granularity. Creates distinct user counts for each combination of day, chain, user type, and product dimensions. Maintains separate tracking for different chains and user types to enable granular analysis. Applies chain availability filtering to ensure only supported chains are included in calculations.
- **Key fields**: `timestamp` (truncated to day), `chain`, `user_type`, `product_id`, `user_address` for distinct counting

### Component C: HyperLogLog initialization for efficient set operations
- **Purpose**: Converts daily user lists into HyperLogLog data structures for memory-efficient distinct counting across time windows  
- **Logic**: Initializes HLL sketches for each daily user set using 15-bit precision. Groups data by timestamp, chain, user type, and product dimensions. Creates HLL structures that can be efficiently merged to count distinct users across overlapping time periods without double-counting.
- **Key fields**: HLL sketches containing compressed user sets, dimensional grouping keys

### Component D: Rolling 7-day window creation
- **Purpose**: Generates complete time series and creates 7-day rolling windows for WAU calculation
- **Logic**: Creates a datespine covering all days from the earliest data to the current date. For each day in the datespine, generates a 7-day window by creating join keys for the current day plus the preceding 6 days. This ensures every day has a complete 7-day lookback period for user counting, even if some days had no activity.
- **Key fields**: `timestamp` for target dates, `joinday` for window day references

### Component E: Window-based user aggregation
- **Purpose**: Calculates distinct users within each 7-day window using HLL merge operations
- **Logic**: Joins the 7-day window structure with daily HLL user data. For each target day, collects HLL sketches from all 7 days in the window. Merges HLL structures using partial merge operations to maintain efficiency while ensuring accurate distinct counting across the full window period.
- **Key fields**: Merged HLL structures representing distinct users in each 7-day period

### Component F: Dimensional breakdown calculation
- **Purpose**: Generates WAU metrics across different analytical dimensions
- **Logic**: Calculates weekly active users separately for four dimensional views: project-level (overall Hop protocol), chain-level (per blockchain), user_type-level (by user classification), and product_id-level (by specific products). Each breakdown groups and merges HLL structures appropriately, with unused dimensions set to null. Extracts final distinct counts from merged HLL sketches using HLL extract functions.
- **Key fields**: `dimensions` identifier, dimensional grouping fields (`chain_id`, `user_type`, `product_id`), extracted `user_wau` counts

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project, chain, user_type, product_id) into a single result set with a common schema structure
- **Time boundary handling**: Uses incremental processing with configurable lookback periods to maintain data freshness while optimizing compute resources
- **Schema standardization**: Applies the `finalize_metric_user_wau` macro to ensure consistent output format, proper data types, and any required business logic standardization
- **Final calculation**: Each row represents the count of distinct users who performed bridge transactions within a 7-day rolling window ending on the specified date, broken down by the specified dimension

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

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

Hop ProtocolHOP

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown