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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique user addresses that interact with PoolTogether protocol within any 30-day rolling window. This metric captures user engagement across deposit, withdrawal, and prize claiming activities on the PoolTogether v4 yield-based savings protocol. The calculation uses HyperLogLog probabilistic data structures to efficiently deduplicate users across multiple days while maintaining accuracy for large user sets.

## 2. Data sources

The MAU calculation relies on the following raw data sources:

- **PoolTogether v4 smart contract events**: Parsed event logs from PoolTogether v4 protocol contracts deployed on Avalanche, Ethereum, Polygon, and Optimism blockchains
- **Prize distribution events**: `ClaimedDraw` events from `PrizeDistributor` contracts (Avalanche, Ethereum, Optimism) and `RewardDistributor` contracts (Polygon) that capture prize claims
- **Pool interaction events**: `Deposited` and `Withdrawal` events from `YieldSourcePrizePool` contracts across all supported chains that capture deposit and withdrawal activities
- **Blockchain transaction metadata**: Block timestamps, transaction hashes, and log indices from the underlying blockchain transactions containing these events

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identifies and categorizes all user interactions with PoolTogether protocol contracts
- **Logic**: Extracts user addresses from three types of smart contract events across four blockchains. Prize claims are captured from `ClaimedDraw` events (using `user` parameter for PrizeDistributor and RewardDistributor contracts), where users are classified as "Withdrawer" type. Deposit activities are captured from `Deposited` events (using `operator` parameter), where users are classified as "Depositor" type. Withdrawal activities are captured from `Withdrawal` events (using `operator` parameter), where users are classified as "Withdrawer" type. All interactions are tagged with market sector as 'asset_management' and business segment as 'yield_aggregator'
- **Key fields**: `block_timestamp` for timing, `user_address` for identification, `chain` for blockchain context, `user_type` for activity classification, `transaction_hash` and `log_index` for deduplication

### Component B: Daily active user calculation
- **Purpose**: Calculates daily unique active users as the foundation for monthly aggregation
- **Logic**: Groups user interactions by day (truncating `block_timestamp` to day boundary) and deduplicates user addresses within each day-chain-user_type combination. Preserves dimensional information including chain, user type, market sector, business segment, and product ID for downstream aggregation. Applies chain availability filters to ensure data quality and consistency
- **Key fields**: `timestamp` (daily), `user_dau` (deduplicated user address), `chain`, `user_type`, `product_id`

### Component C: HyperLogLog conversion and datespine generation
- **Purpose**: Converts daily user sets to probabilistic data structures and creates complete time series
- **Logic**: Transforms daily active user counts into HyperLogLog data structures with 15-bit precision for efficient storage and merging. Creates a comprehensive datespine covering all days from the earliest available data to the current date minus one day. Generates 30-day rolling window joins by pairing each day with its preceding 29 days, creating the foundation for monthly active user calculations
- **Key fields**: `hll` (HyperLogLog user set), `timestamp` (target day), `joinday` (days within 30-day window)

### Component D: Monthly active user window calculation
- **Purpose**: Aggregates users within 30-day rolling windows while avoiding double-counting
- **Logic**: Joins the datespine with daily HyperLogLog data to create 30-day windows for each date. Each window contains up to 30 days of user data (current day plus previous 29 days). Merges HyperLogLog sets within each window using probabilistic union operations that preserve user uniqueness across multiple days. Maintains dimensional breakdowns by chain, user type, and product ID throughout the aggregation process
- **Key fields**: `hll` (merged user sets), dimensional attributes for grouping

### Component E: Dimensional aggregation
- **Purpose**: Calculates MAU across different analytical dimensions
- **Logic**: Extracts final user counts from merged HyperLogLog sets and aggregates across four dimensional levels. Project-level MAU aggregates all users regardless of chain, user type, or product. Chain-level MAU breaks down users by blockchain network. User type MAU separates depositors from withdrawers. Product-level MAU groups by specific product identifiers. Each aggregation nullifies non-relevant dimensions while preserving the target grouping dimension
- **Key fields**: `user_mau` (final count), `dimensions` (aggregation level), `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set containing MAU values at project, chain, user type, and product levels
- **Schema standardization**: Apply the `finalize_metric_user_mau` macro to ensure consistent metric formatting, add metadata fields, and implement zero-filling strategy for missing data points
- **Time boundaries**: Use incremental processing with monthly partitions and apply safety margins for data freshness, filtering results to include only data from the last modified time minus 29 days plus incremental lookback days
- **Final calculation**: The final MAU value represents the estimated count of unique user addresses that interacted with PoolTogether protocol within any 30-day rolling window, calculated using probabilistic HyperLogLog algorithms that provide high accuracy for large-scale user deduplication

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

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

PoolTogetherPOOL

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown