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

## 1. Overview

The Mummy Finance revenue metric measures the protocol's daily revenue generated from trading fees across perpetual and spot trading activities. Revenue is calculated by applying a 40% revenue share to all fees collected by the protocol, with the remaining 60% considered supply-side fees distributed to liquidity providers. This metric answers how much revenue Mummy Finance generates from its derivatives trading platform across Arbitrum, Fantom, and Optimism networks.

## 2. Data sources

The calculation relies on several key data sources:

- **Blockchain events**: Parsed `CollectMarginFees` events from Mummy Finance Vault contracts capturing perpetual trading fees across Arbitrum, Fantom, and Optimism
- **Blockchain events**: Parsed `CollectSwapFees` events from Mummy Finance Vault contracts capturing spot trading fees across the same three networks
- **Token metadata**: Token symbol and decimal information for fee tokens used in the protocol
- **External data**: End-of-day token price feeds for USD conversion of fee amounts
- **Configuration data**: Hardcoded revenue percentage splits defining the protocol's fee distribution model

## 3. Step-by-step calculation

### Component A: Perpetual trading fee collection
- **Purpose**: Captures fees generated from leveraged perpetual trading activities
- **Logic**: Extracts `CollectMarginFees` events from Mummy Finance Vault contracts across Arbitrum, Fantom, and Optimism. Each event contains the fee `token` address and `feeTokens` amount representing trading fees collected. Events are filtered by contract address to ensure only official Mummy Finance contracts are included. The data is classified with business metadata including business line as "Perpetual trading", market sector as "derivatives", and business segment as "perpetual"
- **Key fields**: `block_timestamp` for timing, `token` for fee token address, `feeTokens` for raw fee amount, `address` for user account

### Component B: Spot trading fee collection  
- **Purpose**: Captures fees generated from spot trading activities on the platform
- **Logic**: Extracts `CollectSwapFees` events from the same Vault contracts across all three chains. These events have identical structure to perpetual fees but represent spot trading activity. The fee `token` address and `feeTokens` amount capture swap fees collected from users. Events are classified with business line as "Spot trading" while maintaining the same market sector and business segment classifications
- **Key fields**: `block_timestamp` for timing, `token` for fee token address, `feeTokens` for raw fee amount, `address` for user account

### Component C: Fee aggregation and standardization
- **Purpose**: Combines perpetual and spot fees into a unified dataset with proper token metadata
- **Logic**: Unions perpetual and spot fee events into a single dataset, truncating timestamps to daily boundaries. Joins with token metadata using `chain` and `token_address` to resolve token symbols and decimal places. This standardizes fee data across different tokens and chains while preserving the distinction between perpetual and spot trading activities
- **Key fields**: `timestamp` truncated to day, `token_address` for joining with metadata, `amount` for fee amounts, `token_symbol` from metadata joins

### Component D: USD conversion and decimal correction
- **Purpose**: Converts all fee amounts to USD values for consistent aggregation
- **Logic**: Applies decimal correction based on each token's decimal places from metadata, then converts amounts to USD using end-of-day price feeds. The conversion uses the price on the date of the fee collection to ensure accurate historical valuation. Handles various fee tokens including stablecoins, ETH, and other tokens used for fee payments
- **Key fields**: `fees` as the USD-converted and decimal-corrected fee amounts

### Component E: Revenue percentage application
- **Purpose**: Converts gross fees to protocol revenue using the defined revenue split
- **Logic**: Joins fee data with the revenue percentage configuration, which specifies that 40% of fees constitute protocol revenue starting from December 2, 2022. The percentage is applied as a multiplier to the USD fee amounts. The configuration uses a fill-forward strategy to apply the 40% rate to all dates from the start date onwards
- **Key fields**: `revenue_percentage` set to 0.4 (40%), `revenue` calculated as fees multiplied by revenue percentage

### Final aggregation
- **Combining components**: All fee events are combined through union operations, maintaining separate business line classifications while aggregating to daily totals per chain
- **Currency conversion**: USD conversion occurs before revenue percentage application, using end-of-day price feeds matched to the transaction date
- **Time aggregation**: All timestamps are truncated to daily boundaries, with fees aggregated by date, chain, and business line
- **Final calculation**: Revenue equals total daily fees multiplied by 40%, representing Mummy Finance's share of trading fees collected across both perpetual and spot trading activities

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

Mummy Finance

Revenue

Revenue

Competitive landscape

Chain breakdown