Liquidity providers deposit funds into Everclear and receive transfer fees from users (supply-side fees).

Everclear is a cross-chain liquidity network that enables fully non-custodial transfers between EVM-compatible chains and L2 systems. Everclear was co-founded by  Arjun Bhuptani, Rahul Sethuram, and Layne Haber and launched in 2021.

Everclear team & investors own and govern the protocol. They do not currently take a cut of the total transfer fees paid by users (revenue).

github

twitter

discord

etherscan

website

Bridges

Everclear

# Everclear Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Connext measures the number of unique addresses that have completed bridge transactions through the Connext protocol within any 30-day rolling window. This metric provides insight into user engagement and protocol adoption by tracking distinct users who have successfully executed cross-chain transactions across Connext's supported blockchain networks. The calculation uses HyperLogLog sketching for efficient cardinality estimation and creates multiple dimensional views to analyze user activity across different chains, user types, and product categories.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Connext v1 protocol events**: Parsed `TransactionManager_TransactionFulfilled` events from Ethereum, Arbitrum, Avalanche, BSC, Fantom, Gnosis, Optimism, and Polygon networks, representing completed bridge transactions
- **Connext v2 protocol events**: Parsed `ConnextDiamond_XCalled` events from Ethereum, Arbitrum, BSC, Gnosis, Optimism, and Polygon networks, representing cross-chain function calls
- **Chain availability data**: Metadata indicating which chains are available for analysis during specific time periods

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Identifies all user addresses that have interacted with the Connext protocol across supported chains and protocol versions
- **Logic**: Extracts user addresses from two types of Connext events across eight blockchain networks. For v1 events, the `user` field from `TransactionManager_TransactionFulfilled` events captures addresses that completed bridge transactions. For v2 events, the `params.originSender` field from `ConnextDiamond_XCalled` events captures addresses initiating cross-chain calls. All users are classified as 'Trader' type and categorized under 'bridges' market sector
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for deduplication, `chain` for network identification, `user_address` for unique user identification, and `user_type` set to 'Trader'

### Component B: Daily active user calculation
- **Purpose**: Aggregates user interactions to daily granularity and creates the foundation for rolling window calculations
- **Logic**: Takes all user events and truncates timestamps to day boundaries using `timestamp_trunc`. Creates distinct user counts for each day by removing duplicate addresses that may have multiple transactions on the same day. Groups results by timestamp, chain, user type, and product dimensions. Applies chain availability filtering to ensure only data from available chains is included
- **Key fields**: `timestamp` truncated to daily grain, `chain` for network grouping, `user_type` for user classification, `product_id` for product categorization, and `user_dau` containing unique user addresses

### Component C: HyperLogLog sketch preparation
- **Purpose**: Converts daily active user data into HyperLogLog sketches for efficient cardinality estimation in rolling windows
- **Logic**: Initializes HyperLogLog sketches from daily active user sets using `hll_count.init` with precision parameter 15. Groups data by timestamp, chain, user type, and product dimensions to create sketches that can be efficiently merged for window calculations
- **Key fields**: `timestamp` for daily boundaries, dimensional fields for grouping, and `hll` containing the HyperLogLog sketch of unique users

### Component D: Date spine and window generation
- **Purpose**: Creates a complete date range and generates 30-day rolling windows to ensure no gaps in MAU calculations
- **Logic**: Generates a date spine covering the full time range from earliest DAU data to current date minus one day. For each day in the spine, creates a 30-day window by joining with the previous 29 days using `generate_timestamp_array`. This cross-join produces all day-to-lookback-day combinations needed for rolling window calculations
- **Key fields**: `timestamp` for the current day, `joinday` for each day within the 30-day lookback window

### Component E: Rolling window aggregation
- **Purpose**: Combines HyperLogLog sketches within 30-day windows to calculate monthly active users
- **Logic**: Joins the date spine windows with daily HLL sketches on the lookback days. For each 30-day window, merges all HLL sketches using `hll_count.merge_partial` and extracts the final cardinality using `hll_count.extract`. This produces unique user counts for overlapping 30-day periods
- **Key fields**: `timestamp` for window end date, dimensional grouping fields, and merged `hll` sketches for cardinality calculation

### Component F: Dimensional breakdowns
- **Purpose**: Creates multiple views of MAU data across different analytical dimensions
- **Logic**: Generates four separate breakdowns of the MAU data: project-level (overall protocol MAU), chain-level (MAU per blockchain), user-type-level (MAU by user classification), and product-level (MAU by product category). Each breakdown aggregates the rolling window data by merging HLL sketches and extracting final counts. Non-relevant dimensional fields are set to null using `safe_cast`
- **Key fields**: `timestamp`, `dimensions` indicating breakdown type, relevant dimensional fields, and `user_mau` containing the final count

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using `union all` operations to create a unified MAU dataset with multiple analytical perspectives
- **Schema standardization**: The `finalize_metric_user_mau` macro applies standard schema formatting, ensures consistent field types, and implements a 'fill_zeros' strategy for missing data points
- **Time boundaries**: Incremental processing logic ensures efficient updates by only processing recent time periods while maintaining historical accuracy
- **Final calculation**: The result provides daily MAU values representing unique users active within each 30-day rolling window, broken down by project, chain, user type, and product dimensions

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

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

EverclearCLEAR

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown