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 Revenue Methodology

## 1. Overview

This metric calculates PoolTogether's revenue, which is explicitly set to zero across all time periods and chains. The calculation demonstrates that PoolTogether operates as a no-loss prize savings protocol where all fees collected from prize claiming are paid out to claimers rather than retained as protocol revenue. The underlying data infrastructure tracks fee payments from draw claims across multiple blockchain deployments, but the final revenue metric reflects PoolTogether's design as a zero-revenue protocol.

## 2. Data sources

The calculation utilizes several key data sources:
- **Blockchain events**: Parsed `ClaimedDraw` events from PoolTogether v4 smart contracts across Ethereum, Polygon, Avalanche, and Optimism networks
- **Smart contract data**: Both `PrizeDistributor` and `RewardDistributor` contract events that capture prize claim payouts
- **Transaction data**: Blockchain transaction logs containing payout amounts to prize claimers
- **External data**: End-of-day token price feeds for USD conversion and token metadata for decimal correction
- **Protocol metadata**: Chain-specific contract addresses and token configurations for each PoolTogether v4 deployment

## 3. Step-by-step calculation

### Component A: Draw claim fee extraction
- **Purpose**: Extracts fee payment data from PoolTogether v4 prize claiming events across multiple blockchains
- **Logic**: Processes `ClaimedDraw` events from both `PrizeDistributor` contracts (on Ethereum, Avalanche, Optimism) and `RewardDistributor` contracts (on Polygon). Each event captures when prizes are claimed and includes the `payout` amount paid to the claimer as a fee. The system identifies events by contract address and extracts key fields including block timestamp, transaction hash, log index, account address, and payout amount. Chain-specific token addresses are mapped (USDC on Ethereum `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48`, USDC on Polygon `0x2791bca1f2de4661ed88a30c99a7a9449aa84174`, USDC on Avalanche `0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e`, USDC on Optimism `0x7f5c764cbc14f9669b88837ca1490cca17c31607`)
- **Key fields**: `block_timestamp` for timing, `address` as the claimer account, `payout` as the fee amount, plus chain and version identifiers

### Component B: Daily fee aggregation and USD conversion
- **Purpose**: Aggregates raw fee data into daily totals and converts to USD values
- **Logic**: Groups the extracted fee data by day using timestamp truncation to daily boundaries. Applies the `convert_to_usd_and_correct_decimals` macro to convert token amounts to USD using end-of-day price feeds and correct for token decimal places. The aggregation maintains dimensions for chain, market sector (asset management), business segment (yield aggregator), and product identifiers. Applies the `finalize_metric_fees` macro with a "fill_zeros" strategy to ensure complete time series data and standardize the output schema
- **Key fields**: `timestamp` (daily), `chain_id`, `token_address`, and `fees` (in USD)

### Final aggregation
- **Combining components**: The revenue calculation fetches the processed fees data but explicitly overrides all fee amounts
- **Revenue calculation**: Sets the `revenue` field to 0 for all records, regardless of the underlying fee amounts calculated in previous steps
- **Time aggregation**: Maintains daily timestamp grain from the fees calculation
- **Final calculation**: Applies the `finalize_metric_revenue` macro to ensure schema compliance and data completeness, but the core revenue value remains zero across all time periods and chains. This reflects PoolTogether's protocol design where collected fees are entirely distributed to claimers rather than retained as protocol revenue

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

PoolTogetherPOOL

Revenue

Revenue

Competitive landscape

Chain breakdown