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 Active users (monthly) Methodology

## 1. Overview

The Katana Monthly Active Users (MAU) metric measures the number of unique users who have traded on the Katana decentralized exchange over a rolling 30-day period. This metric provides insight into user engagement and adoption of the Katana AMM protocol on the Ronin blockchain. The calculation uses HyperLogLog sketches for memory-efficient approximate distinct counting across multiple dimensional breakdowns.

## 2. Data sources

- **Ronin blockchain events**: Parsed `Swap` events from Katana v1 AMM pair contracts on the Ronin blockchain, containing trade execution data including token amounts and participant addresses
- **Ronin transaction data**: Transaction records from the Ronin blockchain providing user addresses (`from_address`) for each swap transaction
- **Token metadata**: Protocol-specific metadata identifying Katana as a DEX with "Exchange AMM" business line classification

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Extract and standardize all Katana v1 trading activity from the Ronin blockchain
- **Logic**: Query parsed `Swap` events from Katana v1 pair contracts and join with corresponding transaction records to identify the trading user addresses. Each swap event contains token amount changes (`amount0In`, `amount0Out`, `amount1In`, `amount1Out`) and is associated with the transaction sender as the user address. Events are filtered to include only legitimate trades and classified with protocol metadata (business line as "Exchange AMM", market sector as "exchanges", business segment as "dex").
- **Key fields**: `block_timestamp` for daily aggregation, `user_address` from transaction `from_address` for user identification, `chain` set to "ronin", and protocol classification fields

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users (DAU) from trading activity
- **Logic**: Group swap events by day using `timestamp_trunc` on `block_timestamp` and count distinct `user_address` values for each day. Users are classified as "Trader" user type since they are engaging in trading activity. The calculation produces daily snapshots of unique user addresses who executed at least one trade on that day.
- **Key fields**: `timestamp` truncated to day granularity, `user_dau` containing distinct user addresses, `user_type` set to "Trader", and dimensional attributes like `chain` and `product_id`

### Component C: HyperLogLog conversion
- **Purpose**: Convert daily user counts to HyperLogLog sketches for efficient aggregation
- **Logic**: Transform daily distinct user lists into HyperLogLog sketches using `hll_count.init` with precision parameter 15. This enables memory-efficient approximate distinct counting when merging across multiple days. Each daily record becomes an HLL sketch that can be efficiently combined with other days' sketches.
- **Key fields**: `hll` containing the HyperLogLog sketch representation of daily unique users, along with dimensional grouping fields

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation
- **Logic**: Generate a complete datespine covering all days from the earliest trade date to the current date. For each day in the datespine, create associations with the previous 29 days plus the current day (total 30 days) using `generate_timestamp_array` with 30-day intervals. This ensures no days are skipped even if there were no trades on certain days. Join this window structure with the daily HLL data to collect all relevant daily sketches for each 30-day period.
- **Key fields**: `timestamp` for the end date of each 30-day window, `joinday` representing each of the 30 days in the window period

### Component E: Multi-dimensional MAU aggregation
- **Purpose**: Calculate MAU across different dimensional breakdowns
- **Logic**: For each 30-day window, merge all HLL sketches from the constituent days using `hll_count.merge_partial` and extract the final distinct count using `hll_count.extract`. Create separate aggregations for four dimensional levels: project-level (all dimensions nulled), chain-level (grouped by `chain_id`), user-type-level (grouped by `user_type`), and product-level (grouped by `product_id`). Each aggregation produces MAU counts with different levels of granularity.
- **Key fields**: `user_mau` containing the final monthly active user count, `dimensions` indicating the aggregation level, and the respective dimensional attributes

### Final aggregation
- **Combining components**: Union all dimensional MAU calculations (project, chain, user type, product) into a single result set with consistent schema structure
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily timestamps represent the end date of each rolling 30-day MAU calculation period
- **Final calculation**: The `user_mau` field contains the distinct count of users who traded at least once during the 30-day period ending on each timestamp, calculated using HyperLogLog approximate distinct counting for memory efficiency across the rolling window aggregation

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

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

Katana (Ronin)

Active users (monthly)

Active users (monthly)

Competitive landscape