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

Gnosis Chain is a smart contract platform for decentralized applications (a blockchain). Gnosis was founded by Martin Köppelmann and Stefan George and launched in 2015.

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

governance

github

twitter

discord

etherscan

website

Blockchains (L1)

Gnosis

# Gnosis Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique wallet addresses that initiated at least one transaction on the Gnosis blockchain within any 7-day period. This metric answers the question "How many distinct users are actively transacting on Gnosis each week?" and serves as a key indicator of network adoption and user engagement. The calculation uses a sliding 7-day window approach with HyperLogLog approximation for efficient processing of large transaction datasets.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Gnosis blockchain transactions**: Complete transaction records from the Gnosis blockchain including sender addresses, timestamps, block numbers, gas usage, and transaction hashes
- **Token metadata**: Information about the WXDAI token including contract address and decimal precision
- **Blockchain infrastructure data**: Chain availability information and operational metadata for filtering and validation

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize transaction data from Gnosis blockchain to identify transaction senders
- **Logic**: Raw Gnosis transactions are processed to extract key fields including `block_timestamp`, `from_address`, `to_address`, `transaction_hash`, and gas-related information. The `from_address` field represents the wallet address that initiated each transaction and serves as the user identifier. Transactions are classified with market sector as "blockchains_l1", business segment as "blockchain", and chain as "gnosis". Gas prices are converted from wei to ETH by dividing by 10^18. The WXDAI token address is hardcoded as the native token reference.
- **Key fields**: `block_timestamp` for temporal analysis, `from_address` as the unique user identifier, `transaction_hash` for deduplication, and gas usage metrics

### Component B: Daily active user calculation  
- **Purpose**: Aggregate unique transaction senders by day to establish daily active user counts
- **Logic**: Transaction data is grouped by truncated day using `timestamp_trunc(block_timestamp, day)` to establish daily boundaries. For each day, distinct `from_address` values are identified as unique users who sent at least one transaction. Each unique sender address on a given day counts as one daily active user regardless of transaction volume. Users are classified as "Transaction sender" type. The data includes dimensional breakdowns by chain, product, and user type for flexible aggregation.
- **Key fields**: `timestamp` (day-truncated), `user_dau` (unique sender address), `user_type`, `chain`, `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily unique users into efficient probabilistic data structures for approximate counting
- **Logic**: Daily active user lists are transformed into HyperLogLog sketches using `hll_count.init()` with precision parameter 15, which provides high accuracy (standard error ~0.4%) while enabling efficient storage and computation. Each day's unique users are converted into a single HyperLogLog sketch that can be merged with other sketches to calculate unique counts across time periods. This approach allows for efficient calculation of rolling windows without storing complete user lists.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, dimensional grouping fields

### Component D: Rolling 7-day window construction
- **Purpose**: Create sliding 7-day windows for each day to calculate weekly active users
- **Logic**: A datespine is generated covering the full date range of available data using `generate_timestamp_array()`. For each target day, a 7-day lookback window is created spanning from 6 days prior through the current day. This creates overlapping windows where each day serves as the end date for its own weekly calculation. The datespine ensures consistent windows even when some days have no transaction activity. Join operations connect each target day with the 7 preceding days to establish the rolling window boundaries.
- **Key fields**: `timestamp` (target day), `joinday` (days within the 7-day window), window boundary dates

### Component E: Weekly active user aggregation
- **Purpose**: Calculate unique users active within each 7-day window using HyperLogLog merging
- **Logic**: For each 7-day window, the HyperLogLog sketches from constituent days are merged using `hll_count.merge_partial()` to create a combined sketch representing all users active during the window. The final unique count is extracted using `hll_count.extract()`, which provides the approximate number of distinct users who were active on any day within the 7-day period. This sliding window approach means a user active on multiple days within a week is counted only once for that week.
- **Key fields**: `user_wau` (weekly active users), `timestamp` (week end date), dimensional breakdowns

### Component F: Dimensional breakdown calculation
- **Purpose**: Generate weekly active user counts across multiple analytical dimensions
- **Logic**: Weekly active user calculations are performed separately for different dimensional breakdowns: chain-level aggregation groups by `chain_id` only, project-level aggregation combines all data under 'project_dbt_tag' dimension, user-type-level aggregation groups by `user_type`, and product-level aggregation groups by `product_id`. Each breakdown uses the same HyperLogLog merging logic but with different grouping criteria. Results are unioned together to provide a comprehensive view across all analytical dimensions.
- **Key fields**: `dimensions` (breakdown type), `user_wau`, relevant dimensional fields, null values for non-applicable dimensions

### Final aggregation
- **Combining components**: The weekly active user data filtered for 'chain' and 'project_dbt_tag' dimensions is selected and the `user_wau` field is renamed to `active_addresses_weekly` to align with the target metric definition
- **Currency conversion**: No currency conversion is applied as this is a count-based metric measuring unique addresses rather than monetary values  
- **Time aggregation**: Weekly boundaries are calculated using 7-day sliding windows where each day represents the end date of a weekly period spanning the previous 6 days plus the current day
- **Final calculation**: The final metric value equals the HyperLogLog-approximated count of unique wallet addresses that sent at least one transaction within any 7-day period, calculated using probabilistic counting with ~99.6% accuracy and standardized through the finalization macro with zero-filling for missing days

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

Unique active addresses over a rolling 7-day window.

GnosisGNO

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape