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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user of the PoolTogether protocol. This metric is calculated by dividing daily revenue by daily active users. For PoolTogether, this metric consistently equals $0 because PoolTogether operates as a zero-revenue protocol that does not extract fees from user interactions, instead functioning as a no-loss savings game where users earn yield and have chances to win prizes.

## 2. Data sources

The calculation uses the following raw data sources:
- **Blockchain events**: Parsed PoolTogether v4 `ClaimedDraw` events from PrizeDistributor and RewardDistributor contracts across Ethereum, Polygon, Avalanche, and Optimism networks
- **Pool interaction events**: Parsed `Deposited` and `Withdrawal` events from YieldSourcePrizePool contracts on all supported chains
- **External data**: End-of-day USDC price feeds for each supported network and token metadata for USDC contracts (used for data structure consistency but not actual revenue calculation)
- **Token data**: Contract addresses and decimal configurations for USDC tokens on Ethereum (0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48), Polygon (0x2791bca1f2de4661ed88a30c99a7a9449aa84174), Avalanche (0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e), and Optimism (0x7f5c764cbc14f9669b88837ca1490cca17c31607)

## 3. Step-by-step calculation

### Component A: User interaction tracking
- **Purpose**: Identify all users who actively interact with PoolTogether pools on each day
- **Logic**: Parse blockchain events from PoolTogether v4 contracts to extract user addresses and classify interaction types. Extract user addresses from `Deposited` events (classified as "Depositor"), `Withdrawal` events (classified as "Withdrawer"), and `ClaimedDraw` events (classified as "Withdrawer"). Process events from YieldSourcePrizePool contracts for deposits and withdrawals, and from PrizeDistributor/RewardDistributor contracts for prize claims. All events are timestamped to the day level and tagged with chain, market sector ("asset_management"), and business segment ("yield_aggregator")
- **Key fields**: `user_address` (extracted from event parameters like `user` or `operator`), `user_type` (Depositor/Withdrawer), `block_timestamp` (converted to daily boundaries), `chain` (network identifier)

### Component B: Daily active user aggregation
- **Purpose**: Calculate distinct daily active users using efficient aggregation methods
- **Logic**: Group user interactions by day and count distinct user addresses using HyperLogLog algorithm with precision 15. Create aggregations across multiple dimensions including project-level totals, chain-specific breakdowns, user type breakdowns, and product-specific breakdowns. The HyperLogLog approach enables efficient distinct counting while supporting various dimensional analyses
- **Key fields**: `user_dau` (distinct user count), `timestamp` (daily boundary), `dimensions` (aggregation level), `chain_id`, `user_type`, `product_id`

### Component C: Revenue determination
- **Purpose**: Set protocol revenue values for ARPU calculation
- **Logic**: PoolTogether operates as a zero-revenue protocol that does not extract fees from user interactions. Revenue is explicitly set to 0 for all time periods, chains, and products. While the system tracks prize claim payout amounts from `ClaimedDraw` events, these represent prize distributions to users rather than revenue to the protocol. The fee tracking infrastructure exists for data consistency but all revenue values are hardcoded to 0
- **Key fields**: `revenue` (always 0), `timestamp` (daily boundary), `chain_id`, `product_id`

### Final aggregation
- **Combining components**: The ARPU calculation divides daily revenue (always $0) by daily active users using the calculate_arpu macro. This creates a metric that consistently equals $0 across all time periods and dimensions
- **Currency conversion**: Not applicable since revenue is always 0, but the underlying infrastructure supports USD conversion of USDC amounts using end-of-day price feeds
- **Time aggregation**: All calculations use daily boundaries with timestamps truncated to day level using timestamp_trunc function
- **Final calculation**: ARPU = Daily Revenue ÷ Daily Active Users = $0 ÷ DAU = $0 per user per day. Missing data points are filled with zeros using the fill_zeros strategy, and chain availability filters are applied to ensure data quality

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

PoolTogetherPOOL

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape