Liquidity providers deposit funds into PoolTogether and receive a return on investment in lottery winnings (supply-side fees).

PoolTogether is an asset management (no-loss lottery) protocol built on Ethereum and other adjacent blockchains. PoolTogether was founded by Leighton Cusack and launched in 2019.

POOL tokenholders own and govern the protocol. They currently do not take a cut of the total return on investment paid by liquidity providers (revenue). PoolTogether’s investors include IDEO CoLab Ventures, DTC Capital, ConsenSys Ventures, etc.

governance

github

twitter

discord

etherscan

website

Asset management

PoolTogether

# PoolTogether Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of distinct users who interact with PoolTogether protocol within any 7-day rolling window. This metric captures user engagement across the protocol's core activities: depositing funds into prize pools, withdrawing funds, and claiming prizes. The calculation uses HyperLogLog data structures for efficient approximate counting and provides dimensional breakdowns by blockchain, user activity type, and product.

## 2. Data sources

- **PoolTogether V4 contract events**: Parsed smart contract events from PoolTogether V4 protocol across four blockchains
- **Ethereum events**: `PrizeDistributor` `ClaimedDraw` events, `YieldSourcePrizePool` `Deposited` and `Withdrawal` events
- **Polygon events**: `RewardDistributor` `ClaimedDraw` events, `YieldSourcePrizePool` `Deposited` and `Withdrawal` events  
- **Avalanche events**: `PrizeDistributor` `ClaimedDraw` events, `YieldSourcePrizePool` `Deposited` and `Withdrawal` events
- **Optimism events**: `PrizeDistributor` `ClaimedDraw` events, `YieldSourcePrizePool` `Deposited` and `Withdrawal` events
- **Transaction metadata**: Block timestamps, transaction hashes, and log indices for event ordering and deduplication

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify and classify all user interactions with PoolTogether protocol contracts
- **Logic**: Extract user addresses from three types of PoolTogether contract events across four blockchains. For `ClaimedDraw` events, extract the `user` parameter and classify as "Withdrawer". For `Deposited` events, extract the `operator` parameter and classify as "Depositor". For `Withdrawal` events, extract the `operator` parameter and classify as "Withdrawer". Each interaction includes block timestamp, transaction hash, log index, blockchain identifier, and user classification. All interactions are categorized under the "asset_management" market sector and "yield_aggregator" business segment.
- **Key fields**: `user_address` (the interacting wallet), `user_type` (Depositor or Withdrawer), `chain` (blockchain identifier), `block_timestamp` (transaction timing), `transaction_hash` and `log_index` (for event uniqueness)

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct active users from the extracted user interactions
- **Logic**: Group user interactions by day using timestamp truncation to daily boundaries. Count distinct user addresses per day, maintaining breakdowns by blockchain, user activity type, market sector, business segment, and product identifier. Apply chain availability filtering to ensure data quality and completeness. Store results with daily timestamp grain for downstream rolling window calculations.
- **Key fields**: `timestamp` (daily boundary), `user_dau` (distinct daily active user address), `chain` (blockchain), `user_type` (activity classification), `product_id` (product identifier)

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily active user sets into memory-efficient HyperLogLog data structures for scalable aggregation
- **Logic**: Initialize HyperLogLog sketches from daily active user counts using 15-bit precision for balance between accuracy and storage efficiency. Group sketches by timestamp, chain, user type, and product dimensions. HyperLogLog enables approximate distinct counting that scales efficiently for large user sets and time windows.
- **Key fields**: `hll` (HyperLogLog sketch containing user cardinality), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window construction
- **Purpose**: Create 7-day rolling windows for weekly active user calculation while handling missing days correctly
- **Logic**: Generate a complete daily date spine from the earliest available data through yesterday to ensure no temporal gaps. For each date in the spine, create a 7-day lookback window spanning the current day plus the previous 6 days. Join this expanded date range with the daily HLL sketches to capture all user activity within each rolling window. Missing days in the source data are handled gracefully through the complete date spine approach.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within the 7-day window), `hll` (daily user sketches within the window)

### Component E: Weekly aggregation and dimensional breakdowns
- **Purpose**: Calculate weekly active users across multiple dimensional views by merging HyperLogLog sketches within each 7-day window
- **Logic**: For each 7-day window, merge the daily HyperLogLog sketches using HLL merge operations to count distinct users across the full week, automatically handling overlaps between days. Generate four dimensional breakdowns: overall project level (all dimensions collapsed), by blockchain chain, by user activity type (Depositor vs Withdrawer), and by product identifier. Each breakdown nullifies non-relevant dimensions while preserving the target dimension for analysis.
- **Key fields**: `user_wau` (weekly distinct active users), `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id` (dimensional attributes)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set containing project-level, chain-level, user-type-level, and product-level weekly active user metrics
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro to standardize output schema, assign the "pooltogether" data identifier, and implement a "fill_zeros" strategy for missing periods
- **Time boundary handling**: Filter results to maintain incremental processing boundaries and data freshness, ensuring efficient updates while preserving historical accuracy
- **Final calculation**: The final `user_wau` value represents the approximate count of distinct users who performed any PoolTogether interaction (deposit, withdrawal, or prize claim) within each 7-day rolling window, calculated using HyperLogLog merge operations for scalable cardinality estimation

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

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

PoolTogetherPOOL

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown