Validators process & store the uploaded data and collect upload & storage fees from data uploaders (supply-side fees).

Swarm is a data storage network built on Gnosis. Swarm was founded by Viktor Tron, Jeffrey Wilcke and Daniel A. Nagy and launched in 2016.

BZZ tokenholders own and govern the protocol. They currently don’t take a cut of the fees paid by data uploaders.

github

twitter

discord

etherscan

website

Infrastructure

Swarm

# Swarm Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Swarm measures the number of unique users who interact with Swarm's decentralized storage protocol within any 7-day period. This metric answers the business question "How many distinct users are actively engaging with Swarm infrastructure weekly?" The calculation uses a rolling 7-day window approach with HyperLogLog data structures for efficient cardinality estimation across multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Swarm protocol events**: Parsed `PostageStamp_BatchCreated_event` logs from Gnosis chain, capturing users who create new postage stamp batches
- **Swarm top-up events**: Parsed `PostageStamp_BatchTopUp_event` logs from Gnosis chain, identifying batch top-up transactions
- **Token transfer events**: Gnosis chain `Transfer` events for BZZ token (address `0xdbf3ea6f5bee45c02255b2c26a16f300502f68da`) filtered by recipient address
- **Contract interaction data**: Transaction logs for the Swarm PostageStamp contract (`0x30d155478ef27ab32a1d578be7b84bc5988af381`) on Gnosis chain

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Identifies unique user addresses interacting with Swarm protocol and classifies them by interaction type
- **Logic**: Extracts user addresses from two types of Swarm events on Gnosis chain. For `PostageStamp_BatchCreated_event`, identifies the `owner` field as "Batch Creator" users. For "Batch TopUpper" users, joins `PostageStamp_BatchTopUp_event` with BZZ token transfer events where the recipient is the PostageStamp contract address, extracting the `from_address` as the user
- **Key fields**: `block_timestamp` for timing, `user_address` for unique identification, `user_type` for classification, `chain` set to 'gnosis', `market_sector_id` set to 'infrastructure'

### Component B: Daily active user aggregation
- **Purpose**: Aggregates identified users into daily active user counts with dimensional breakdowns
- **Logic**: Groups user interactions by day using timestamp truncation, maintaining dimensions including chain, user type, market sector, business segment, and product. Creates distinct daily user lists grouped by these dimensions to eliminate duplicate counting within the same day
- **Key fields**: `timestamp` truncated to day granularity, `timestamp_grain` set to 'day', `user_dau` containing unique user addresses, dimensional fields for breakdowns

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user lists into memory-efficient HyperLogLog sketches for cardinality estimation
- **Logic**: Initializes HLL sketches from daily user data using `hll_count.init()` function with 15-bit precision. Groups data by timestamp, chain, user type, and product dimensions while creating HLL representations of user sets
- **Key fields**: `hll` containing HyperLogLog sketches, dimensional grouping fields preserved from daily data

### Component D: Rolling window generation
- **Purpose**: Creates 7-day rolling windows to capture weekly active user periods
- **Logic**: Generates a complete datespine covering the analysis period to prevent missing timestamps. For each date, creates a 7-day lookback window using `generate_timestamp_array()` with 6-day intervals (current day plus 6 previous days). Joins this window structure with daily HLL data to create rolling 7-day periods
- **Key fields**: `timestamp` for the window end date, `joinday` for individual days within each window, HLL sketches for each day in the window

### Component E: Dimensional breakdown calculation
- **Purpose**: Calculates WAU across multiple dimensional levels for comprehensive analysis
- **Logic**: Merges HLL sketches within each 7-day window using `hll_count.merge_partial()` function, then extracts final unique counts using `hll_count.extract()`. Calculates separate WAU values for four dimensional levels: project-level (overall Swarm), chain-level, user-type-level (Batch Creator vs Batch TopUpper), and product-level breakdowns. Uses null casting for dimensions not relevant to each breakdown level
- **Key fields**: `user_wau` containing final weekly active user counts, `dimensions` indicating breakdown level, dimensional fields set appropriately for each breakdown

### Final aggregation
- **Combining components**: Unions all dimensional breakdown results into a single dataset, preserving the dimensional structure with appropriate null values for unused dimensions
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily boundaries with 7-day rolling windows, ensuring complete coverage through datespine generation and safety margins for incremental processing
- **Final calculation**: The final `user_wau` value represents the count of unique users who had any interaction with Swarm protocol within the 7-day period ending on the given timestamp, calculated using HyperLogLog cardinality estimation for memory efficiency

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

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

SwarmBZZ

Active users (weekly)

Active users (weekly)

Competitive landscape