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 Trade count Methodology

## 1. Overview

The HoneyPop trade count metric measures the daily number of unique trading transactions executed on HoneyPop's automated market maker (AMM) pools. This metric counts distinct transactions that contain swap events, providing insight into the trading activity and user engagement on the HoneyPop DEX platform. The calculation aggregates unique transaction hashes daily across all HoneyPop pools to avoid double-counting multiple swaps within the same transaction.

## 2. Data sources

The calculation relies on several key blockchain and reference data sources:

- **Blockchain events**: Parsed Scroll blockchain `Pool_Swap_event` logs from HoneyPop V1 pools containing swap transaction details including token amounts, pool addresses, and sender information
- **Pool creation events**: Scroll blockchain `Factory_PoolCreated_event` logs from the HoneyPop V1 factory contract that define trading pairs, fee tiers, and pool configurations  
- **Transaction data**: Scroll blockchain transaction records providing transaction metadata and user address mapping
- **Token metadata**: Reference data containing token symbols, decimal places, and contract addresses for proper amount conversion and pair identification
- **Denylist data**: Configuration data for excluding trading pairs with limited liquidity or price feed support (currently empty for HoneyPop)

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract and process raw swap events from HoneyPop V1 pools on Scroll
- **Logic**: Query `Pool_Swap_event` logs from HoneyPop V1 pools to capture swap transactions. Each event contains the pool address, sender address (`sender`), and token amounts for both sides of the trade (`amount0`, `amount1`). Join with Scroll transaction records to map the contract sender to the actual user address (`from_address`) who initiated the transaction. Filter out any trading pairs that appear in the denylist (currently no pairs are denylisted for HoneyPop). Classify all trades with business metadata including 'Exchange AMM' business line, 'dex' business segment, and 'exchanges' market sector.
- **Key fields**: `transaction_hash`, `log_index`, `account_address` (pool), `amount0`, `amount1`, `sender`, `user_address`

### Component B: Trading pair enrichment  
- **Purpose**: Add trading pair metadata and token information to enable proper processing
- **Logic**: Join swap events with trading pair dimensions built from `Factory_PoolCreated_event` logs. This provides token addresses for both tokens in the pair (`token0_address`, `token1_address`), fee tier information, and token decimal places from the token metadata. The trading pair dimensions also include token symbols for pair naming and decimal places required for amount conversion.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, `account_name`

### Component C: Amount normalization and time aggregation
- **Purpose**: Convert raw token amounts to decimal-adjusted values and aggregate to daily time boundaries
- **Logic**: Convert raw token amounts from their native integer representation to decimal-adjusted amounts by dividing by 10 raised to the power of each token's decimal places. Apply absolute values to handle the directional nature of swap amounts (positive/negative based on swap direction). Truncate block timestamps to daily boundaries to enable daily aggregation. This creates the foundation dataset with normalized amounts and consistent time granularity.
- **Key fields**: `timestamp` (daily), `token0_amount` (normalized), `token1_amount` (normalized)

### Final aggregation
- **Combining components**: The processed trade data flows through the intermediate volume model which handles amount normalization and daily aggregation
- **Trade counting**: Count distinct transaction hashes grouped by daily timestamp, chain, and product to determine unique trading transactions per day. This approach ensures that transactions containing multiple swap events are counted only once
- **Time series completion**: Apply the `finalize_metric_trade_count` macro with 'fill_zeros' strategy to ensure complete daily time series with zero values for days without trades
- **Final calculation**: The final trade count represents the number of unique transactions containing HoneyPop swap events for each day, providing a measure of daily trading activity on the platform

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

Number of trades executed on a decentralized exchange.

Honeypop

Trade count

Trade count

Competitive landscape