Validators process transactions and receive fees from users (supply-side fees).

Conflux is a smart contract platform for decentralized applications (a blockchain). Conflux was founded by David Chow, Fan Long, Ming Wu, and YuanJie Zhang and launched in 2020. Note that this dashboard only includes Conflux Core Space.

CFX holders own and govern the protocol. They currently do not take a cut of the total transaction fees paid by users (revenue).

governance

github

twitter

discord

website

Blockchains (L1)

Conflux Core Space

# Conflux Core Space Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Conflux blockchain within a 7-day rolling window. This metric provides insight into user engagement and network activity by tracking the distinct transaction senders over weekly periods. The calculation uses HyperLogLog sketches for efficient approximate counting of unique addresses across rolling 7-day windows.

## 2. Data sources

The methodology relies on the following raw data sources:
- **Conflux blockchain transactions**: Raw transaction records from the Conflux network containing sender addresses, transaction hashes, and block timestamps
- **Block timestamp data**: Precise timing information for each transaction to enable daily and weekly aggregations
- **Transaction metadata**: Transaction hash identifiers and sender address information for unique user identification

## 3. Step-by-step calculation

### Component A: User address extraction
- **Purpose**: Identifies unique transaction sender addresses from raw Conflux blockchain data
- **Logic**: Extracts sender addresses from raw Conflux transactions, setting the user type as 'Transaction sender' and market sector as 'blockchains_l1'. Each transaction record provides the `block_timestamp`, `transaction_hash`, and `sender` address. The data is classified with chain identifier 'conflux' and business segment 'blockchain'
- **Key fields**: `block_timestamp` for timing, `sender` as the user address, `transaction_hash` for transaction identification

### Component B: Daily active user calculation  
- **Purpose**: Creates daily snapshots of unique active users by aggregating distinct sender addresses per day
- **Logic**: Transaction timestamps are truncated to day granularity using timestamp truncation. Distinct sender addresses are counted per day to create daily active user records. Each daily record contains the truncated timestamp, timestamp grain 'day', chain information, user type, and the unique user address
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` set to 'day', `user_address` containing the distinct sender addresses

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily user addresses into HyperLogLog sketches for efficient approximate counting
- **Logic**: Daily unique user addresses are processed using BigQuery's `hll_count.init()` function with precision parameter 15 to create HyperLogLog sketches. This enables efficient approximate counting of unique addresses across time windows without storing individual addresses
- **Key fields**: `hll` containing the HyperLogLog sketch representation of daily unique addresses

### Component D: Rolling window generation
- **Purpose**: Creates 7-day rolling windows for weekly active user calculation
- **Logic**: A datespine generates all possible dates from the minimum transaction date to the current date. For each date, a 7-day window is created by generating timestamps from 6 days prior to the current day. This creates overlapping 7-day periods that allow calculation of rolling weekly metrics
- **Key fields**: `timestamp` for the end date of each 7-day window, `joinday` representing each day within the window

### Component E: Weekly active user aggregation
- **Purpose**: Calculates unique addresses across 7-day rolling windows using HLL merge operations
- **Logic**: HyperLogLog sketches from daily user data are joined with the 7-day rolling windows. Sketches within each 7-day window are merged using `hll_count.merge_partial()` to combine unique address counts, then extracted using `hll_count.extract()` to produce the final weekly active user count. This process maintains approximate uniqueness across the entire 7-day period
- **Key fields**: `user_wau` containing the count of unique weekly active users

### Component F: Dimensional breakdown
- **Purpose**: Provides weekly active user metrics across different analytical dimensions
- **Logic**: Weekly active users are calculated and grouped by four different dimensions: project dbt tag level (aggregated across all chains), chain level (Conflux-specific), user type level (transaction senders), and product level. Each breakdown uses the same HLL merge logic but groups by different dimensional attributes
- **Key fields**: `dimensions` indicating the breakdown level, `chain_id`, `user_type`, `product_id` for dimensional grouping

### Final aggregation
- **Combining components**: Weekly active user calculations from all dimensional breakdowns are combined using UNION ALL operations. The target model filters this data to include only 'chain' and 'project_dbt_tag' dimensions
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: Weekly boundaries are created using 7-day rolling windows, with each day representing the end of a 7-day period
- **Final calculation**: The final metric renames `user_wau` to `active_addresses_weekly` and applies chain availability filtering. The result represents the approximate count of unique addresses that sent transactions within each 7-day rolling window on the Conflux blockchain

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

Unique active addresses over a rolling 7-day window.

Conflux Core SpaceCFX

Archived

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape