Liquidity providers deposit funds into Clipper and receive returns generated by Clipper’s costless diversified rebalancing liquidity pools (supply-side fees). LP yields are generated from the rebalancing process itself rather than from fees charged to traders.

Clipper is a non-custodial exchange protocol built on Ethereum. Clipper was built by Shipyard Software and launched in 2021.

AdmiralDAO and SAIL token holders own and govern the protocol. They currently receive all trading fees paid by traders (revenue). Clipper's investors include Polychain, Robot Ventures, 0x Labs, etc.

github

twitter

discord

etherscan

website

Exchanges (DEX)

Clipper

# Clipper Trade count Methodology

## 1. Overview

The Clipper trade count metric measures the daily number of unique trades executed on the Clipper decentralized exchange (DEX) across multiple blockchain networks. This metric counts distinct trading transactions rather than individual swaps, providing insight into trading activity and user engagement on the platform. The calculation aggregates unique transaction hashes from Clipper's various contract versions across Ethereum, Polygon, Optimism, and Arbitrum networks.

## 2. Data sources

The calculation relies on several key data sources:

- **Clipper swap events**: Parsed `Swapped` event logs from multiple Clipper contract versions across four chains:
  - Ethereum: `ApproximateCaravelExchange`, `VerifiedCaravelExchange`, `CaravelExchange`, and `ExchangeInterface` contracts
  - Polygon: `VerifiedExchange` and `DirectExchange` contracts  
  - Optimism: `PackedVerifiedExchange` and `PackedExchange` contracts
  - Arbitrum: `PackedVerifiedExchange` contracts
- **Transaction records**: Blockchain transaction data from Ethereum, Polygon, Optimism, and Arbitrum to link swap events with user addresses
- **Token metadata**: Token information including symbols, decimal precision, and contract addresses for amount normalization
- **End-of-day price feeds**: Daily token price data across all supported chains for USD conversion in intermediate calculations

## 3. Step-by-step calculation

### Component A: Raw trade event extraction
- **Purpose**: Collect all Clipper swap events across multiple chains and contract versions
- **Logic**: Extract `Swapped` events from various Clipper exchange contracts deployed across Ethereum, Polygon, Optimism, and Arbitrum. Each contract version represents different iterations of the Clipper protocol. Events contain swap details including input token (`inAsset`), output token (`outAsset`), input amount (`inAmount`), output amount (`outAmount`), contract address, transaction hash, and log index. Join with transaction records to enrich events with user addresses (`from_address` field).
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `address` (contract), `inAsset` and `outAsset` (token addresses), `inAmount` and `outAmount` (raw token quantities), `from_address` (user)

### Component B: Trading volume processing
- **Purpose**: Process swap events into standardized trading records with USD valuations
- **Logic**: Group swap events by day using timestamp truncation. Join with token metadata to correct decimal precision for token amounts using division by 10^decimals. Calculate absolute values of token amounts and aggregate by transaction. Join with end-of-day price feeds to convert token amounts to USD values. Apply anti-manipulation logic by taking the lesser USD value between the two tokens in each swap to filter out potential price manipulation attempts.
- **Key fields**: `timestamp` (day-truncated), `token0_amount` and `token1_amount` (decimal-corrected), `trading_volume` (USD value using minimum of both token values)

### Component C: Trade count aggregation  
- **Purpose**: Count unique trades per day across all dimensions
- **Logic**: From the processed trading volume data, count distinct transaction hashes grouped by day, chain, market sector identifier, business segment identifier, and product identifier. Each unique transaction hash represents one trade regardless of how many individual token swaps it contains. Group by timestamp grain (daily), chain identifier, and business classification dimensions.
- **Key fields**: `trade_count` (count of distinct `transaction_hash` values), dimensional groupings including `chain_id`, `market_sector_id` ('exchanges'), `business_segment_id` ('dex')

### Final aggregation
- **Combining components**: The processed trade counts are passed through the `finalize_metric_trade_count` macro with a fill-zeros strategy to ensure complete daily records across all time periods and dimensions
- **Currency conversion**: No currency conversion applied at final stage since the metric counts transactions rather than values
- **Time aggregation**: Daily boundaries are established using day-truncated timestamps with 'day' granularity labels  
- **Final calculation**: The final metric value is the count of distinct transaction hashes per day, ensuring each unique trade is counted exactly once regardless of the number of token swaps within that transaction. Chain availability filtering is applied to exclude data from chains that are not currently active or available.

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

Number of trades executed on a decentralized exchange.

ClipperSAIL

Trade count

Trade count

Competitive landscape

Chain breakdown