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

## 1. Overview

SolidLizard revenue represents trading fees claimed by protocol-controlled gauges from decentralized exchange pools. This metric captures the protocol's fee income by tracking when liquidity incentive distributors (gauges) claim accumulated trading fees from AMM pools. The calculation aggregates fee claims across all SolidLizard trading pairs, converts multi-token fees to USD values, and provides daily revenue totals.

## 2. Data sources

The revenue calculation relies on the following raw data sources:

- **Fee claim events**: Arbitrum `Pair_Claim_event` logs from SolidLizard trading pair contracts that record when fees are claimed, including the claiming address and amounts for both tokens in each pair
- **Trading pair creation events**: Arbitrum `PairFactory_PairCreated_event` logs that establish trading pair contracts and their underlying token compositions
- **Gauge creation events**: Arbitrum `Voter_GaugeCreated_event` logs that map gauge addresses to their corresponding pool addresses, enabling identification of protocol-controlled fee claims
- **Token price data**: End-of-day price feeds providing USD values for tokens involved in fee claims
- **Token metadata**: Token information including decimal precision and symbols for proper unit conversion and display

## 3. Step-by-step calculation

### Component A: Fee claim event extraction
- **Purpose**: Captures all instances when fees are claimed from SolidLizard trading pairs
- **Logic**: Extracts Arbitrum `Pair_Claim_event` logs from SolidLizard pair contracts. Each event contains the pair contract address, the address claiming the fees, and the amounts claimed for both tokens in the pair. Events are classified with business metadata including market sector as "exchanges", business segment as "dex", and business line as "Exchange AMM"
- **Key fields**: `block_timestamp` for timing, `address` as the pair contract, `sender` as the fee collector address, `amount0` and `amount1` as raw token amounts claimed

### Component B: Trading pair metadata
- **Purpose**: Provides token composition and metadata for each trading pair
- **Logic**: Uses `PairFactory_PairCreated_event` logs to identify all trading pair contracts and their underlying token addresses. Joins with token metadata to retrieve decimal precision and symbols for both tokens in each pair. Creates human-readable pair names by combining token symbols
- **Key fields**: `account_address` as the pair contract, `token0_address` and `token1_address` for the two tokens, `token0_decimals` and `token1_decimals` for decimal conversion, `account_name` as the formatted pair identifier

### Component C: Gauge-pool mapping
- **Purpose**: Identifies which fee claims represent protocol revenue versus user claims
- **Logic**: Extracts `Voter_GaugeCreated_event` logs to map gauge addresses to their corresponding pool addresses. Gauges are protocol-controlled contracts that distribute liquidity incentives and claim fees on behalf of the protocol. This mapping enables filtering to include only fee claims made by gauges, ensuring the metric captures protocol revenue rather than individual user fee claims
- **Key fields**: `incentive_account_address` as the gauge address, `exchange_account_address` as the associated pool address

### Component D: Daily fee aggregation and decimal correction
- **Purpose**: Aggregates fee claims by day and converts raw token amounts to proper decimal representation
- **Logic**: Groups fee claim events by day using `timestamp_trunc` to daily boundaries. Joins fee claims with trading pair metadata to access token decimal information. Converts raw token amounts to proper decimal representation by dividing `amount0` and `amount1` by 10 raised to the power of their respective token decimals. Sums corrected amounts across all claims for each pair per day
- **Key fields**: `timestamp` as daily boundary, `token0_amount` and `token1_amount` as decimal-corrected fee amounts

### Component E: USD conversion
- **Purpose**: Converts token amounts to USD values using end-of-day pricing
- **Logic**: Joins daily fee amounts with end-of-day price feeds for both tokens in each trading pair. Multiplies the decimal-corrected token amounts by their respective USD prices and sums the results to get total USD value of fees claimed per pair per day. Uses coalesce with zero fallback to handle cases where price data may be unavailable
- **Key fields**: `price_usd` from price feeds, calculated `fees` as the USD sum of both token values

### Final aggregation
- **Combining components**: Fee claims are filtered through an inner join with gauge-pool mappings to ensure only protocol-controlled claims are included. This filtering step is crucial as it distinguishes between protocol revenue (gauge claims) and user activity (individual claims)
- **Currency conversion**: All fee amounts are converted to USD using end-of-day price feeds matched by timestamp, chain, and token address. The conversion handles dual-token fees by summing USD values from both tokens in each pair
- **Time aggregation**: Events are aggregated to daily boundaries using `timestamp_trunc`, with all claims within a calendar day grouped together
- **Final calculation**: The metric applies the `finalize_metric_revenue` macro to standardize the schema, validate business IDs, fill gaps with zeros where no revenue occurred, and apply chain availability filters. The result provides daily protocol revenue totals across all SolidLizard trading pairs on Arbitrum

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

SolidLizardSLIZ

Revenue

Revenue

Competitive landscape