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

Katana is a non-custodial exchange protocol built on Ronin. Katana was founded by Sky Mavis and launched in 2021.

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

github

twitter

discord

website

Exchanges (DEX)

Katana (Ronin)

# Katana Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user on the Katana decentralized exchange. This metric answers the business question: "How much revenue does each user generate on average per day?" The calculation divides daily protocol revenue by the number of daily active users, providing insight into user value and monetization efficiency.

## 2. Data sources

The ARPU calculation relies on several key data sources:
- **Blockchain events**: Parsed Katana v1 `Swap` events from the Ronin blockchain that capture all trading activity including token amounts and user interactions
- **Trading pair data**: `PairCreated` events from Katana's factory contract that define available trading pairs and their fee structures
- **Transaction data**: Ronin blockchain transaction records that provide user addresses and transaction context
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols, decimals, and names
- **Manual configurations**: Hardcoded token information for special cases like Smooth Love Potion (SLP) token

## 3. Step-by-step calculation

### Component A: Trading activity extraction
- **Purpose**: Captures all trading activity and calculates net token changes for each swap
- **Logic**: Extracts swap events from Katana v1 pairs on Ronin blockchain. For each swap, calculates net token changes by subtracting `amount0Out` from `amount0In` for token0 and `amount1Out` from `amount1In` for token1. Joins with transaction data to identify the user address initiating each trade. Filters to only include valid trading activity with proper transaction context.
- **Key fields**: `token0_amount` and `token1_amount` represent net changes in token balances, `user_address` identifies the trader, `account_address` identifies the trading pair contract

### Component B: Trading pair metadata
- **Purpose**: Provides essential information about each trading pair including tokens and fee structures
- **Logic**: Processes `PairCreated` events to build a registry of all trading pairs. For each pair, extracts the two token addresses and applies a standard fee tier of 3000 basis points (0.3%). Enriches with token metadata including decimals and symbols from both the standard token registry and manual token configurations. Creates human-readable pair names by combining token symbols.
- **Key fields**: `token0_address` and `token1_address` identify the pair tokens, `fee_tier` defines the trading fee rate, `token0_decimals` and `token1_decimals` enable proper decimal corrections

### Component C: Trading volume calculation
- **Purpose**: Converts raw token amounts to USD-denominated trading volumes
- **Logic**: Joins trading activity with pair metadata to access token information. Applies decimal corrections by dividing token amounts by 10 raised to the power of token decimals. Converts corrected amounts to USD using end-of-day price feeds for both tokens. Implements manipulation protection by taking the minimum USD value between token0 and token1 calculations. Aggregates volumes daily by summing all trading activity per day.
- **Key fields**: `trading_volume` represents the daily USD volume after decimal correction and price conversion, `timestamp` truncated to day level for daily aggregation

### Component D: Fee calculation
- **Purpose**: Calculates total trading fees generated from volume and fee rates
- **Logic**: Multiplies daily trading volume by the fee tier (0.3% for Katana v1) to determine total fees collected. Uses the standard AMM model where fees are charged on each swap based on the trading volume. Aggregates fees across all trading pairs and days to get total daily fee collection.
- **Key fields**: `fees` represents total daily fees in USD, calculated as trading volume multiplied by fee tier

### Component E: Revenue calculation
- **Purpose**: Determines protocol revenue as Ronin's share of collected fees
- **Logic**: Applies a protocol fee share of 1/6 (approximately 16.67%) to the total fees. This represents the portion of fees that accrue to Ronin as the protocol operator, while the remaining 5/6 goes to liquidity providers. Maintains daily granularity and preserves all dimensional breakdowns from the fee calculation.
- **Key fields**: `revenue` represents daily protocol revenue in USD, calculated as fees multiplied by the 1/6 protocol share

### Component F: Daily active user counting
- **Purpose**: Counts unique users who performed trades each day
- **Logic**: Identifies unique user addresses from trading activity on each day. Uses HyperLogLog sketches for efficient counting across different dimensional breakdowns including by chain, user type, and product. Applies timestamp truncation to day level to ensure proper daily boundaries. Excludes any system or contract addresses, focusing only on actual user trading activity.
- **Key fields**: `user_dau` represents the count of distinct active users per day, `user_type` categorizes users as 'Trader' based on their activity

### Final aggregation
- **Combining components**: The ARPU calculation uses a macro that joins daily revenue data with daily active user counts on matching timestamp and dimensional attributes. Both metrics are aggregated to the same daily level ensuring consistent time boundaries.
- **Currency conversion**: All revenue values are already in USD from the earlier trading volume conversion step using end-of-day price feeds. No additional currency conversion is needed at this stage.
- **Time aggregation**: Both revenue and user counts use day-level timestamp truncation with consistent timezone handling. Missing days are filled with zeros to ensure complete time series.
- **Final calculation**: ARPU is calculated by dividing daily revenue by daily active users. When daily active users is zero, the result is also zero. The calculation preserves dimensional breakdowns allowing ARPU analysis by chain, product, and user type.

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

Katana (Ronin)

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape