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

Mummy Finance is a non-custodial exchange for spot and perpetual contracts built on Fantom, Optimism, and Arbitrum. Mummy Finance was founded by an anonymous team and was launched in December 2022.

MMY tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

github

twitter

discord

etherscan

website

Derivative exchanges

Mummy Finance

# Mummy Finance Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who actively traded on Mummy Finance within any 30-day rolling window. This metric tracks traders who performed derivatives trading activities (position increases, decreases, or swaps) across Mummy Finance's perpetual trading protocol on Arbitrum, Fantom, and Optimism chains. The calculation uses HyperLogLog sketches for efficient approximate distinct counting and provides breakdowns across multiple dimensions including chain, user type, and product level.

## 2. Data sources

- **Blockchain events**: Parsed `IncreasePosition`, `DecreasePosition`, and `Swap` events from Mummy Finance Vault smart contracts across Arbitrum, Fantom, and Optimism chains
- **Transaction data**: Blockchain transaction timestamps and transaction hashes for event timing and deduplication
- **Smart contract interactions**: Events from Mummy V1 Vault contracts on all chains, plus Mummy V2 Vault contracts specifically on Fantom
- **Chain availability data**: Configuration data to ensure proper data quality filtering across supported blockchain networks
- **Protocol metadata**: Market sector classification (derivatives) and business segment identification (perpetual trading)

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identifies active traders from blockchain events and standardizes user classification
- **Logic**: Extracts user addresses from three types of Mummy Finance trading events across supported chains. On Arbitrum and Optimism, captures interactions with V1 Vault contracts. On Fantom, captures interactions with both V1 and V2 Vault contracts. All identified users are classified as "Trader" type since these events represent active trading behaviors. The `account` field from each event provides the trader's wallet address
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for deduplication, `chain` for network identification, `account` field renamed to `user_address` for the trader's wallet address, `user_type` set to "Trader" for all users

### Component B: Daily active user calculation  
- **Purpose**: Aggregates unique user addresses into daily active user counts across multiple dimensions
- **Logic**: Groups user activity by day using timestamp truncation to daily boundaries. Creates distinct counts of user addresses for each combination of day, chain, user type, and product. Applies chain availability filtering to ensure data quality. Sets market sector to "derivatives" and business segment to "perpetual" for all records
- **Key fields**: `timestamp` truncated to day level, `user_address` for distinct counting, `chain`, `user_type`, `product_id`, dimension fields for classification

### Component C: HyperLogLog sketch preparation
- **Purpose**: Converts daily user counts into memory-efficient probabilistic data structures for scalable distinct counting
- **Logic**: Transforms daily active user data into HyperLogLog sketches using 15-bit precision via `hll_count.init(user_dau, 15)`. Groups sketches by timestamp, chain, user type, and product dimensions to prepare for window-based aggregation
- **Key fields**: `hll` containing the HyperLogLog sketch data structure, maintained grouping dimensions from daily aggregation

### Component D: 30-day rolling window creation
- **Purpose**: Generates a complete datespine and creates 30-day rolling windows for MAU calculation
- **Logic**: Creates a continuous date range from the earliest user activity date to current date minus 1 day. For each date in the spine, generates join relationships with the 29 preceding days (creating 30-day total windows). This ensures every day has a complete 30-day lookback period for MAU calculation, preventing gaps in the time series
- **Key fields**: `timestamp` for the window end date, `joinday` representing each day within the 30-day window period

### Component E: Window aggregation
- **Purpose**: Joins daily HLL sketches with the 30-day window structure to capture user activity across rolling periods
- **Logic**: Combines the rolling window datespine with daily HyperLogLog sketches by matching join days with actual activity dates. This creates a dataset where each row represents one day's contribution to a specific 30-day MAU window, maintaining all dimensional groupings
- **Key fields**: `timestamp` for window end date, `hll` for the daily user sketch, dimension fields (`chain_id`, `user_type`, `product_id`) for breakdown maintenance

### Component F: Multi-dimensional MAU calculation
- **Purpose**: Calculates final MAU values across four different dimensional breakdowns
- **Logic**: Creates four separate aggregations by merging HLL sketches across 30-day windows. Project-level MAU combines all chains and dimensions. Chain-level MAU groups by individual blockchain networks. User-type-level MAU groups by trader classifications. Product-level MAU groups by product identifiers. Uses `hll_count.merge_partial(hll)` to combine sketches and `hll_count.extract()` to get final distinct counts
- **Key fields**: `user_mau` containing the final distinct user count, `dimensions` indicating the breakdown type, relevant grouping fields populated while others set to null

### Final aggregation
- **Combining components**: Unions all four dimensional breakdowns (project, chain, user type, product) into a single dataset using UNION ALL operations
- **Time aggregation**: Maintains daily granularity with 30-day rolling windows, using timestamp truncation for consistent daily boundaries
- **Final calculation**: Applies the `finalize_metric_user_mau` macro with zero-filling strategy to handle missing days and standardize the output schema with proper metric metadata and project identification
- **Incremental processing**: Implements incremental updates with configurable lookback periods to balance data freshness with processing efficiency, using table modification timestamps to determine refresh boundaries

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

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

Mummy Finance

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown