Honeypop is an AMM and concentrated liquidity layer on Scroll, built for efficient swaps and real yield. It will also feature a Morpho-powered money market, enabling seamless lending and borrowing.

twitter

website

Exchanges (DEX)

Honeypop

# Honeypop Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average revenue generated per daily active user on the Honeypop protocol. ARPU is calculated by dividing total revenue by the number of daily active users. For Honeypop, this metric consistently equals zero because the protocol does not capture revenue from its fee-generating activities, despite generating fees from trading and flash loan volumes.

## 2. Data sources

The ARPU calculation relies on the following raw data sources:

- **Blockchain events**: Parsed Scroll blockchain event logs including `Pool_Swap_event` for trading activities, `Pool_Flash_event` for flash loan activities, and `Factory_PoolCreated_event` for trading pair creation
- **Transaction data**: Scroll blockchain transaction records containing user addresses and transaction metadata
- **Token metadata**: Token information including decimals and symbols for proper amount calculations
- **External data**: End-of-day price feeds for USD conversions (used in related volume calculations but not directly in ARPU)

## 3. Step-by-step calculation

### Component A: Daily active users calculation
- **Purpose**: Count unique users who interact with the Honeypop protocol daily through trading or flash loan activities
- **Logic**: Extract user addresses from both trading events (`Pool_Swap_event`) and flash loan events (`Pool_Flash_event`) on the Scroll blockchain. Join event data with transaction records to obtain the actual user addresses (`from_address`) rather than contract addresses. Aggregate unique users daily using approximate distinct counting, classifying all users as 'Trader' type. Apply filters to exclude denylisted trading pairs that have limited price feed support for low liquidity tokens.
- **Key fields**: `user_address` (from transaction `from_address`), `block_timestamp` for daily grouping, `account_address` for pair filtering

### Component B: Revenue calculation  
- **Purpose**: Calculate total revenue captured by the protocol
- **Logic**: The revenue component is explicitly set to zero for all time periods and dimensions. While the protocol generates fees from trading volume and flash loan volume (calculated by multiplying volumes by fee tiers), Honeypop does not capture any of these fees as revenue. The revenue calculation pulls the same dimensional structure as the fees calculation but overrides all fee values to zero.
- **Key fields**: `revenue` (always 0), `timestamp`, `chain_id`, `product_id`

### Component C: User aggregation breakdowns
- **Purpose**: Provide different dimensional views of daily active users
- **Logic**: Create multiple aggregation levels including project-level totals, chain-level breakdowns, user type breakdowns, and product-level breakdowns. Use approximate distinct counting to handle large datasets efficiently while maintaining accuracy for metric calculations.
- **Key fields**: `dimensions` (aggregation level), `user_dau` (distinct user count), dimensional identifiers

### Final aggregation
- **Combining components**: Use the `calculate_arpu` macro to divide revenue by daily active users. Since revenue is always zero, this calculation results in ARPU = 0 / DAU = 0 for all time periods
- **Currency conversion**: No currency conversion needed as revenue values are hardcoded to zero
- **Time aggregation**: Daily boundary logic groups users and revenue by day using timestamp truncation
- **Final calculation**: ARPU = Total Revenue ÷ Daily Active Users = 0 ÷ DAU = 0 for all periods and dimensions

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

Honeypop

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape