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

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with SolidLizard DEX over rolling 7-day periods. This metric answers how many distinct traders are actively using the SolidLizard decentralized exchange on a weekly basis. The calculation uses HyperLogLog sketches for efficient distinct user counting across multiple dimensional breakdowns and applies a rolling window approach to calculate weekly activity.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Swap events**: Parsed `Swap` events from SolidLizard V1 pair contracts deployed on Arbitrum, containing trade execution details including token amounts, user addresses, and swap directions
- **Transaction data**: Arbitrum transaction records providing transaction metadata including the originating user address (`from_address`) and block timestamps
- **Chain configuration**: Chain availability filters to ensure data quality and completeness across supported networks

## 3. Step-by-step calculation

### Component A: Trade event processing
- **Purpose**: Extract and normalize swap trading activity from SolidLizard DEX contracts
- **Logic**: The system identifies all `Swap` events emitted by SolidLizard V1 pair contracts on Arbitrum. For each swap, it calculates the net token amount changes by computing the difference between input and output amounts for both tokens in the pair (`amount0In - amount0Out` and `amount1In - amount1Out`). The swap events are joined with Arbitrum transaction records to retrieve the originating user address from the `from_address` field, ensuring proper user attribution. Each trade is classified with business metadata including business line as "Exchange AMM", market sector as "exchanges", and business segment as "dex"
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for unique identification, `contract_user_address` from swap sender, actual `user_address` from transaction origin, and calculated `token0_amount` and `token1_amount` representing net position changes

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily distinct active users from trading activity
- **Logic**: Trading events are aggregated by truncating `block_timestamp` to day granularity. For each day, the system counts distinct user addresses who executed at least one swap transaction. Users are classified as "trader" type since all activity represents trading behavior. The calculation groups by timestamp (day), chain, user type, market sector, business segment, and product identifiers to maintain dimensional granularity
- **Key fields**: `timestamp` truncated to day, `user_address` as the distinct user identifier, `user_type` set to "trader", and dimensional fields like `chain`, `product_id`, `market_sector_id`, and `business_segment_id`

### Component C: HyperLogLog initialization
- **Purpose**: Prepare daily user data for efficient weekly aggregation using probabilistic counting
- **Logic**: Daily active user data is processed through HyperLogLog initialization to create probabilistic sketches that enable efficient distinct counting across time windows. Each day's user set is converted into an HLL sketch with precision parameter 15, which provides high accuracy for distinct counting while maintaining computational efficiency. The sketches are grouped by timestamp, chain, user type, and product dimensions to maintain all necessary breakdowns
- **Key fields**: `hll` sketch containing the probabilistic representation of daily unique users, maintained alongside all dimensional grouping fields

### Component D: Rolling window construction
- **Purpose**: Create 7-day rolling windows for weekly active user calculation
- **Logic**: A date spine is generated covering the full date range from the earliest available data to the current date minus one day. For each date in the spine, a 7-day window is constructed by joining with the 6 preceding days plus the current day. This creates a rolling window structure where each date has associated data from itself and the previous 6 days, forming complete 7-day periods. The window construction uses timestamp array generation to create all necessary date combinations
- **Key fields**: `timestamp` for the window end date and `joinday` representing each day within the 7-day window period

### Component E: Weekly aggregation by dimensions
- **Purpose**: Calculate weekly active users across multiple dimensional breakdowns
- **Logic**: The system processes the rolling window data to create four distinct dimensional views. For overall project-level WAU, all HLL sketches within each 7-day window are merged regardless of other dimensions. For chain-level breakdown, sketches are merged within each chain separately. For user-type breakdown, sketches are merged by user type classification. For product-level breakdown, sketches are merged by product identifier. Each breakdown involves merging the HLL sketches from all days within the 7-day window and extracting the final distinct count estimate
- **Key fields**: `user_wau` containing the final weekly distinct user count, `dimensions` indicating the breakdown type, and the relevant dimensional fields (`chain_id`, `user_type`, `product_id`) with null values for non-applicable dimensions

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using union operations to create a comprehensive dataset containing WAU metrics at project, chain, user type, and product levels within a single result set
- **Time aggregation**: Daily boundaries are determined by truncating block timestamps to day granularity, with weekly windows calculated as rolling 7-day periods ending on each date
- **Schema finalization**: The finalization process applies the standard Token Terminal metric schema, sets the data identifier to "solidlizard", and fills missing dates with zero values to ensure complete time series data
- **Final calculation**: Weekly Active Users represents the distinct count of user addresses who executed at least one swap transaction within any 7-day rolling period, calculated using HyperLogLog probabilistic counting for computational efficiency and accuracy

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

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

SolidLizardSLIZ

Active users (weekly)

Active users (weekly)

Competitive landscape