Mode Network batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense).

Mode Network is an L2 smart contract platform for decentralized applications on Ethereum. Mode Network was founded by James Ross and launched in 2024.

Mode Network team & investors own and govern the protocol. Mode Network has received a $6 million grant from the Optimism Foundation.

github

twitter

discord

website

Blockchains (L2)

Mode Network

# Mode Network Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Mode blockchain within a rolling 7-day window. This metric answers the business question: "How many distinct users are actively transacting on Mode each week?" The calculation uses a rolling window approach with HyperLogLog probabilistic data structures to efficiently handle large sets of addresses and account for users who are active on multiple days within the same week.

## 2. Data sources

The metric relies on the following raw data sources:
- **Mode blockchain transactions**: Complete transaction records from the Mode blockchain including transaction hashes, block timestamps, and sender addresses
- **Block timestamps**: Precise timing information for when transactions were included in Mode blockchain blocks
- **Transaction sender addresses**: The `from_address` field from Mode transactions representing the address that initiated each transaction

## 3. Step-by-step calculation

### Component A: Transaction sender extraction
- **Purpose**: Identify all unique addresses that have initiated transactions on Mode
- **Logic**: Extract transaction records from Mode blockchain data, focusing on the sender address (`from_address`) and block timestamp for each transaction. All addresses are classified as "Transaction sender" user type since Mode is a blockchain where activity is measured by transaction initiation. The system also assigns metadata including chain identifier ('mode'), market sector ('blockchains_l2'), and business segment ('blockchain')
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for uniqueness, `from_address` as the user identifier, and `chain` for network identification

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users and prepare them for weekly aggregation
- **Logic**: Group transactions by day using timestamp truncation to day boundaries, then identify distinct sender addresses for each day. Create HyperLogLog sketches for each day's unique addresses using precision level 15, which provides efficient storage and merging capabilities for large address sets. The daily aggregation ensures each address is only counted once per day regardless of how many transactions they sent
- **Key fields**: `timestamp` (truncated to day), `user_address` as the unique identifier, and `user_dau` representing daily active users

### Component C: Weekly rolling window construction
- **Purpose**: Build 7-day rolling windows for weekly active address calculation
- **Logic**: Create a continuous datespine covering all dates from the earliest transaction to the current date minus one day. For each date in the datespine, generate a 7-day lookback window including that date plus the previous 6 days. Join this window structure with the daily HLL sketches to create a comprehensive view where each date has access to HLL data from its 7-day period. This approach ensures no gaps in the time series and handles cases where certain days may have no transaction activity
- **Key fields**: `timestamp` for the target date, `joinday` for the window dates, and `hll` containing the HyperLogLog sketches for each day

### Component D: HyperLogLog aggregation by dimensions
- **Purpose**: Calculate weekly active users across different analytical dimensions
- **Logic**: For each 7-day window, merge the HLL sketches using `hll_count.merge_partial` to combine user sets across the 7 days while automatically handling overlaps (users active on multiple days). Extract the final unique count using `hll_count.extract`. Create separate aggregations for different dimensions: chain-level (aggregating across all users for the Mode chain), project-level (aggregating across all users for the entire project), user-type-level (breaking down by transaction sender type), and product-level (though Mode doesn't have distinct products, this maintains schema consistency)
- **Key fields**: `user_wau` as the weekly active user count, `dimensions` to specify aggregation level, and dimensional identifiers like `chain_id`

### Final aggregation
- **Combining components**: The weekly active user values calculated through HLL aggregation are directly mapped to weekly active addresses since each user is represented by a unique blockchain address
- **Currency conversion**: No currency conversion is needed as this metric counts addresses rather than monetary values  
- **Time aggregation**: Uses rolling 7-day windows where each day's value represents unique addresses active in that day plus the previous 6 days, creating overlapping weekly periods
- **Final calculation**: The `user_wau` values are renamed to `active_addresses_weekly` with filtering applied to include only chain-level and project-level dimensions. Missing days are filled with zeros to ensure continuous time series. The final metric represents the count of unique addresses that initiated at least one transaction within each 7-day rolling window period.

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

Unique active addresses over a rolling 7-day window.

Mode NetworkMODE

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown