Liquidity providers deposit funds into SpookySwap and receive trading fees from traders (supply-side fees).

SpookySwap is a non-custodial exchange protocol built on Fantom. SpookySwap was launched in April 2021.

BOO tokenholders own and govern the protocol. They currently take a cut of the total interest paid by borrowers (revenue).

governance

github

twitter

discord

website

Exchanges (DEX)

SpookySwap

# SpookySwap Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for SpookySwap measures the number of unique users who performed trades on the SpookySwap decentralized exchange within a rolling 30-day window. This metric answers the business question: "How many distinct traders are actively using SpookySwap each month?" The calculation uses HyperLogLog algorithms for memory-efficient approximate counting of unique users across sliding time windows.

## 2. Data sources

The calculation relies on the following raw data sources:
- **SpookySwap swap events**: Parsed `Pair_Swap` events from SpookySwap v1 smart contracts on the Fantom blockchain, containing swap amounts, token addresses, and transaction details
- **Fantom transaction records**: Complete transaction data from the Fantom blockchain including user addresses (`from_address`) and transaction metadata
- **Chain availability metadata**: Data quality filters to ensure accurate chain coverage and exclude periods with incomplete data

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Extract and standardize all trading activity from SpookySwap contracts
- **Logic**: Parse `Pair_Swap` events from SpookySwap v1 contracts on Fantom blockchain. Join swap events with corresponding transaction records to obtain the actual user addresses (`from_address`). Filter for transactions occurring from April 17, 2021 onwards. Calculate token amount changes by subtracting output amounts from input amounts for both tokens in each pair. Classify all activity under the 'Exchange AMM' business line and 'dex' business segment.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for event identification, `user_address` from transaction data, token amounts (`amount0In`, `amount0Out`, `amount1In`, `amount1Out`) for swap calculations

### Component B: Daily active user calculation
- **Purpose**: Identify unique users who traded each day
- **Logic**: Group all trading activity by calendar day using timestamp truncation to day granularity. For each day, collect all unique `user_address` values from trading activity. Classify all users as 'Trader' type since this metric focuses on trading activity. Store the daily unique user addresses as the foundation for rolling window calculations.
- **Key fields**: `timestamp` truncated to day, `user_address` as the unique identifier, `user_type` set to 'Trader', chain and product classification fields

### Component C: HyperLogLog sketch initialization
- **Purpose**: Convert daily user lists into memory-efficient approximate counting structures
- **Logic**: Initialize HyperLogLog sketches for each day's unique user set using precision parameter 15, which provides good accuracy while maintaining computational efficiency. Group data by timestamp, chain, user type, and product dimensions. The HLL sketches allow efficient merging across time windows without storing actual user addresses.
- **Key fields**: `hll` sketch containing compressed user count data, dimension fields for proper grouping

### Component D: Rolling window creation
- **Purpose**: Create 30-day sliding windows for MAU calculation
- **Logic**: Generate a complete date spine covering the entire data period to avoid gaps in the time series. For each date in the spine, create associations with the previous 29 days to form 30-day windows. This ensures every day has a complete 30-day lookback period. Handle incremental updates by focusing on recent periods while maintaining sufficient lookback for accuracy.
- **Key fields**: `timestamp` as the window end date, `joinday` representing each day within the 30-day window

### Component E: Window aggregation and HLL merging
- **Purpose**: Calculate monthly active users by merging daily HLL sketches within each window
- **Logic**: For each 30-day window, collect all HLL sketches from the constituent days. Merge the sketches using HyperLogLog partial merge operations to combine unique user counts across the time period. Extract the final approximate count from the merged sketch. This approach efficiently handles overlapping users across multiple days without double-counting.
- **Key fields**: Merged `hll` sketches, extracted `user_mau` counts

### Final aggregation
- **Combining components**: Create separate aggregations for different dimensional breakdowns: project-level (all SpookySwap activity), chain-level (Fantom), user-type-level (Trader), and product-level breakdowns. Union all dimensional views into a single comprehensive dataset.
- **Time aggregation**: Use calendar day boundaries with 30-day rolling windows. Each date represents the MAU count for the 30-day period ending on that date.
- **Final calculation**: Apply the finalize_metric_user_mau macro to standardize schema, fill missing periods with zeros, and ensure consistent output format across all Token Terminal metrics. The final MAU value represents the approximate count of unique users who traded within the trailing 30-day period.

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

Unique revenue-generating users over a rolling 30-day window.

SpookySwapBOO

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown