# SUNSwap V1 Trade count Methodology

## 1. Overview

Trade count measures the number of trades executed on a decentralized exchange. It shows how frequently users are buying or selling assets through the project. For SUNSwap V1, this metric is utilized to analyze user activity, liquidity pool engagement, and transaction frequency on the Tron blockchain. Each individual swap event emitted by a SUNSwap V1 liquidity pool is counted as a single trade.

## 2. Data sources

- **Blockchain events**: `TokenPurchase` and `TrxPurchase` events from `Exchange` contracts, covering Tron

## 3. Step-by-step calculation

### Component A: SUNSwap V1 swap event extraction

- **Purpose**: Extract individual swap transactions from SUNSwap V1 contracts.
- **Logic**: `TokenPurchase` and `TrxPurchase` events are parsed from `Exchange` contracts on Tron. For `TokenPurchase` events, the amount of TRX sold and assets bought are extracted. For `TrxPurchase` events, the amount of TRX bought and assets sold are extracted. Transactions are filtered to include only those occurring on or after August 14, 2020, to align with the launch of the protocol.
- **Key fields**: `block_timestamp` (timing), `transaction_hash` (transaction identification), `log_index` (event ordering), `buyer` (user address), and asset amounts (`trx_sold`, `tokens_bought`, `trx_bought`, `tokens_sold`).

### Component B: Trade count aggregation

- **Purpose**: Aggregate the extracted events into daily trade counts.
- **Logic**: The extracted swap events are grouped by day, chain, and product ID. The total number of trades is calculated by counting the individual swap events within each daily interval. A multi-hop route that interacts with multiple pools is counted as multiple distinct trades, with each pool interaction contributing one trade to the total count.
- **Key fields**: `timestamp` (daily truncated block timestamp), `chain_id` (blockchain identifier), `product_id` (set to SUNSwap V1), and `trade_count` (the aggregated count of events).

### Component C: Standardization and zero-filling

- **Purpose**: Standardize the schema and ensure continuous daily data.
- **Logic**: The aggregated trade counts are cast to standardized data types. Missing days in the time series are filled with zeros to ensure data continuity. Chain availability filters are applied to align the data with approved tracking periods.
- **Key fields**: `timestamp`, `chain_id`, `product_id`, and `trade_count`.

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

Number of trades executed on a decentralized exchange.

Trade count