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

## 1. Overview

The Honeypop revenue metric measures the protocol's revenue from its decentralized exchange operations on Scroll. Currently, Honeypop operates with zero revenue despite collecting fees from trading and flash loan activities. The calculation infrastructure tracks all fee-generating activities but sets the final revenue value to 0, indicating that all collected fees are distributed to liquidity providers rather than retained as protocol revenue.

## 2. Data sources

The methodology uses several key data sources from the Scroll blockchain and external systems:

- **Blockchain events**: Parsed Scroll `Pool_Swap_event` logs capturing all trading activity, `Pool_Flash_event` logs for flash loan transactions, and `Factory_PoolCreated_event` logs for trading pair creation and fee tier configuration
- **Transaction data**: Scroll transaction records linking blockchain events to user addresses and transaction context
- **External data**: End-of-day token price feeds for USD conversion and token metadata registry containing decimals and symbol information
- **Configuration data**: Trading pair denylist for tokens with limited price feed support (currently empty but available for future use)

## 3. Step-by-step calculation

### Component A: Trading volume calculation
- **Purpose**: Calculates USD trading volume from swap activities to determine potential fee generation
- **Logic**: Extracts `Pool_Swap_event` logs from Scroll containing `amount0` and `amount1` fields representing token quantities exchanged. Joins with trading pair metadata from `Factory_PoolCreated_event` logs to get `token0_address`, `token1_address`, and `fee_tier` information. Corrects raw token amounts by dividing by token decimals from metadata registry. Converts both token amounts to USD using end-of-day price feeds matched by timestamp, token address, and chain. Uses the minimum USD value between the two tokens (`least(token0_usd, token1_usd)`) to prevent price manipulation from extreme price differences. Filters out any denylisted trading pairs and aggregates by day
- **Key fields**: `token0_amount` and `token1_amount` from swap events, `fee_tier` from factory events, `price_usd` from price feeds

### Component B: Flash loan volume calculation  
- **Purpose**: Calculates USD flash loan volume to determine flash loan fee generation
- **Logic**: Extracts `Pool_Flash_event` logs from Scroll containing `amount0` and `amount1` fields for borrowed token quantities. Joins with trading pair metadata to identify token addresses and fee tiers. Corrects token amounts using decimals and converts both tokens to USD using end-of-day price feeds. Sums both token USD values (`token0_usd + token1_usd`) to capture total flash loan exposure. Aggregates by day and excludes denylisted trading pairs
- **Key fields**: `token0_amount` and `token1_amount` from flash events, `fee_tier` for fee calculation, `price_usd` for USD conversion

### Component C: Fee calculation
- **Purpose**: Calculates total fees generated from both trading and flash loan activities
- **Logic**: Multiplies trading volume by corresponding `fee_tier` to get trading fees. Multiplies flash loan volume by `fee_tier` to get flash loan fees. Combines both fee streams and aggregates across all trading pairs and activity types. Fee tiers are expressed as decimals (e.g., 0.003 for 0.3% fee)
- **Key fields**: `trading_volume`, `flash_loan_volume`, `fee_tier` for fee rate application

### Final aggregation
- **Combining components**: Sums trading fees and flash loan fees across all trading pairs and chains to get total protocol fees
- **Currency conversion**: All amounts converted to USD using end-of-day price feeds matched by timestamp and token address
- **Time aggregation**: Daily boundaries using timestamp truncation to day level
- **Final calculation**: Despite calculating total fees collected, the final revenue value is hardcoded to 0 for all records. This indicates that Honeypop currently operates as a zero-revenue protocol where all fees are passed through to liquidity providers rather than retained as protocol revenue. The fee calculation infrastructure remains in place to support potential future revenue models.

*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.

Honeypop

Revenue

Revenue

Competitive landscape