Liquidity providers deposit funds into SolidLizard and stake their LP tokens to receive SLIZ tokens (token incentives).

SolidLizard is a non-custodial exchange protocol built on Arbitrum. SolidLizard was founded by an anonymous team and launched in 2023.

SLIZ tokenholders own and govern the protocol. They vote for pools where they wish to receive trading fees and external bribes from, while pools receive SLIZ emissions in respect to their share of votes.

twitter

discord

etherscan

website

Exchanges (DEX)

SolidLizard

# SolidLizard Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who traded on SolidLizard DEX within any 30-day rolling window. This metric answers the business question "How many unique traders used SolidLizard over the past month?" and uses a rolling window approach rather than calendar months to provide more granular trend analysis. The calculation employs HyperLogLog sketches for memory-efficient computation of unique user counts across large datasets.

## 2. Data sources

- **Blockchain events**: Parsed `Swap` events from SolidLizard v1 Pair contracts on Arbitrum, containing swap transaction details, token amounts, and contract addresses
- **Transaction data**: Arbitrum transaction records providing transaction metadata and user wallet addresses
- **Chain availability data**: Metadata ensuring data completeness and quality for supported blockchain networks

## 3. Step-by-step calculation

### Component A: Trade event processing
- **Purpose**: Extract all trading activity from SolidLizard DEX contracts and identify unique traders
- **Logic**: Process `Swap` events from SolidLizard v1 Pair contracts on Arbitrum. For each swap event, join with corresponding Arbitrum transaction records to extract the user's wallet address from the `from_address` field. Calculate the net change in token amounts by subtracting outgoing amounts from incoming amounts for both tokens in the pair (`amount0In` - `amount0Out` and `amount1In` - `amount1Out`). Classify all users as 'trader' type since they are performing swap transactions. Filter events using chain availability metadata to ensure data quality.
- **Key fields**: `block_timestamp` for timing, `user_address` for user identification, `transaction_hash` and `log_index` for event uniqueness, `chain` for network identification, token amount calculations for trade validation

### Component B: Daily active user aggregation  
- **Purpose**: Convert trade events into daily unique user counts using efficient data structures
- **Logic**: Group all trading activity by calendar day using `timestamp_trunc` to day granularity. For each day, chain, and user type combination, collect all unique `user_address` values who performed trades. Convert these daily user lists into HyperLogLog sketches using `hll_count.init` with 15-bit precision for memory-efficient storage and computation of unique counts. This intermediate step enables efficient rolling window calculations in the next phase.
- **Key fields**: `timestamp` truncated to day, `chain` for network grouping, `user_type` always set to 'trader', `user_dau` containing user addresses, HLL sketches for efficient unique counting

### Component C: Rolling window generation
- **Purpose**: Create 30-day rolling windows for each calendar day to calculate monthly active users
- **Logic**: Generate a complete date spine covering all days from the first recorded trading activity through yesterday using `generate_timestamp_array`. For each day in this spine, create a 30-day window that includes the current day plus the 29 preceding days. This is accomplished by generating timestamp arrays that span from 29 days before each date through the date itself. Join these rolling windows with the daily HLL sketches to gather all user activity data within each 30-day period.
- **Key fields**: `timestamp` for the reporting date, `joinday` for each day within the 30-day window, HLL sketches from matching days

### Component D: Monthly active user calculation
- **Purpose**: Merge user activity across 30-day windows and calculate final unique user counts
- **Logic**: For each 30-day window, merge all HLL sketches from the constituent days using `hll_count.merge_partial` to combine the probabilistic data structures. Extract the final unique user count using `hll_count.extract` which provides the estimated count of distinct users across the entire 30-day period. This approach efficiently handles overlapping users across multiple days within each window while maintaining statistical accuracy.
- **Key fields**: Merged HLL sketches, `user_mau` containing final unique user counts

### Component E: Dimensional breakdowns
- **Purpose**: Generate MAU metrics across different business dimensions for analysis flexibility  
- **Logic**: Create four separate dimensional views of the MAU data. The project-level breakdown aggregates all activity regardless of chain or user type. The chain-level breakdown maintains separate counts per blockchain network. The user type breakdown separates different categories of users (though all are 'trader' for SolidLizard). The product breakdown allows for different product offerings within the protocol (currently null for SolidLizard). Each breakdown groups the data differently and merges HLL sketches accordingly while setting non-relevant dimensions to null.
- **Key fields**: `dimensions` indicating the breakdown type, dimensional fields like `chain_id`, `user_type`, `product_id`, final `user_mau` counts

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, preserving the different grouping levels and their respective MAU calculations
- **Time aggregation**: Uses calendar day boundaries with 30-day rolling windows, where each day's MAU represents unique users from that day back 30 days
- **Data quality**: Apply chain availability filters to ensure only complete and reliable data is included in calculations
- **Final calculation**: The final `user_mau` value represents the count of unique wallet addresses that performed at least one trade on SolidLizard within the 30-day rolling window ending on each respective date

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

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

SolidLizardSLIZ

Active users (monthly)

Active users (monthly)

Competitive landscape