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 (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of distinct users who interact with the Mummy protocol within any 7-day rolling window. This metric answers the business question: "How many unique users are actively trading or swapping on Mummy's derivative platform each week?" The calculation uses a rolling 7-day window approach with HyperLogLog data structures for efficient distinct user counting across multiple blockchain networks.

## 2. Data sources

The calculation relies on several key data sources:

- **Blockchain event logs**: Parsed event logs from Mummy protocol smart contracts across Arbitrum, Fantom, and Optimism networks
- **Trading events**: `IncreasePosition` and `DecreasePosition` events that capture when users open, modify, or close derivative trading positions
- **Swap events**: `Swap` events from Mummy Vault contracts that capture token exchange activities
- **Contract interactions**: Event data from multiple Vault contract versions, including Vault and Vault2 contracts on Fantom for comprehensive coverage
- **Transaction metadata**: Block timestamps and transaction hashes associated with each user interaction

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identify all user interactions with Mummy protocol contracts across supported chains
- **Logic**: Extract user addresses and timestamps from parsed blockchain events. Monitor three specific event types: `IncreasePosition` events when users open or increase derivative positions, `DecreasePosition` events when users close or reduce positions, and `Swap` events when users exchange tokens. Cover multiple chains including Arbitrum, Fantom (with both Vault and Vault2 contracts), and Optimism. Classify all users as "Trader" type and assign market sector as "derivatives" and business segment as "perpetual"
- **Key fields**: User address from `account` parameter, block timestamp, transaction hash, chain identifier, and event type classification

### Component B: Daily active user aggregation  
- **Purpose**: Create daily snapshots of distinct active users
- **Logic**: Truncate block timestamps to daily granularity and deduplicate user addresses within each day. Group interactions by timestamp, chain, user type, market sector, business segment, and product to maintain dimensional breakdowns. Apply chain availability filtering to ensure data quality and exclude any invalid or unavailable chain data
- **Key fields**: Daily timestamp, chain identifier, `user_type`, `product_id`, and unique `user_address` for each active day

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into efficient data structures for distinct counting
- **Logic**: Transform daily user lists into HyperLogLog sketches using BigQuery's `hll_count.init` function with 15-bit precision. Group sketches by timestamp, chain, user type, and product dimensions to maintain proper granularity for downstream aggregations. HLL sketches enable memory-efficient approximate distinct counting across large user datasets
- **Key fields**: Daily HLL sketches containing compressed user set information, grouped by dimensional attributes

### Component D: Rolling window construction
- **Purpose**: Create consistent 7-day rolling windows for weekly calculations
- **Logic**: Generate a continuous datespine covering the full time range of available data. For each date in the datespine, create a 7-day window consisting of the current day plus the 6 preceding days. Use jointables approach to map each target date to all 7 contributing dates within its window. This ensures every day has a complete 7-day context for weekly active user calculation, even when some intermediate days have no activity
- **Key fields**: Target timestamp for each weekly calculation, and corresponding array of 7 contributing dates within each window

### Component E: Weekly distinct user calculation
- **Purpose**: Calculate distinct active users across each 7-day window
- **Logic**: For each 7-day window, merge HLL sketches from all contributing days using BigQuery's `hll_count.merge_partial` function. Extract the final distinct count using `hll_count.extract`. This approach accurately counts users who were active on any day within the 7-day period, avoiding double-counting users who were active on multiple days
- **Key fields**: Weekly active user count (`user_wau`) representing distinct users across the full 7-day window

### Component F: Dimensional breakdowns
- **Purpose**: Create multiple analytical views of weekly active users
- **Logic**: Generate four separate dimensional aggregations from the weekly user data. Project-level breakdown provides overall protocol metrics with all dimensional attributes set to null. Chain-level breakdown aggregates by individual blockchain network. User type-level breakdown separates different categories of users. Product-level breakdown distinguishes between different protocol products or features. Combine all breakdowns using union operations to create a comprehensive dimensional dataset
- **Key fields**: Dimension type identifier, relevant dimensional values (`chain_id`, `user_type`, `product_id`), and corresponding weekly active user counts

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single comprehensive table containing project-level, chain-level, user type-level, and product-level weekly active user metrics
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro to standardize output schema, ensure consistent field naming, and apply the "fill zeros" strategy for missing data periods
- **Time aggregation**: Each record represents weekly active users for a specific date using 7-day rolling windows, with daily granularity in the output timeline
- **Final calculation**: The final `user_wau` value represents the distinct count of users who performed at least one tracked action (position change or swap) within the 7-day period ending on the specified date

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

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

Mummy Finance

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown