The 1inch Aggregation Protocol routes users' trades through the most efficient path for a token swap and aggregates multiple non-custodial exchanges.

The 1inch Network unites multiple decentralized protocols built on Ethereum and other blockchains. This dashboard tracks the 1inch Aggregation Protocol, which is a non-custodial DEX aggregator. 1inch was founded by Sergej Kunz & Anton Bukov and launched in 2019.

The 1inch Network is governed by 1inch DAO – a decentralized autonomous organization. Voting on the DAO is performed through the 1INCH token, a governance token, that was initially distributed to the community of 1inch Network users in late 2020. They currently do not take a cut of the total trading fees paid by traders (revenue). 1inch's investors include ParaFi Capital, FTX Exchange, Pantera Capital, etc.

governance

github

twitter

discord

etherscan

website

DEX aggregators

1inch

# 1inch Trade count Methodology

## 1. Overview

The daily number of unique trades executed through the 1inch protocol is measured by the trade count metric. Distinct transactions involving asset swaps are counted, providing insight into daily trading activity and user engagement. Trade data is aggregated from multiple 1inch protocol versions (V1 through V6), with data quality filters applied to ensure accurate counting of legitimate trading activity.

## 2. Data sources

- **Blockchain events**: `Swapped` events from `Mooniswap`, `OneInchExchange`, and `AggregationRouterV3` contracts, `OrderFilled` and `OrderFilledRFQ` events from `AggregationRouterV5` contracts, ERC-20 `Transfer` events, and function calls including `swap`, `unoswap`, `clipperSwap`, and `fillOrder` from `OneInchExchange`, `AggregationRouterV3`, `AggregationRouterV4`, `AggregationRouterV5`, and `AggregationRouterV6` contracts, covering Ethereum, Arbitrum, Base, Polygon, and 7 other chains
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Raw trade data collection

- **Purpose**: Raw trading activities are identified across multiple blockchains and protocol versions.
- **Logic**: Trade data is extracted from three primary sources. First, direct swap events, such as `Swapped` events from `Mooniswap` and `AggregationRouterV3` contracts, are collected. Second, function call traces for swap-related functions across 1inch router versions (V1 through V6) are gathered, with asset addresses and amounts extracted from function parameters and outputs. Third, special function calls that do not emit complete asset information are resolved by joining with ERC-20 `Transfer` events to identify the traded assets. Transaction success filtering is applied to include only completed trades.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `account_address`, `chain`, asset addresses, asset amounts, and user addresses

### Component B: Cross-chain trade consolidation

- **Purpose**: Trade data from all supported blockchains is combined while maintaining chain-specific configurations.
- **Logic**: Trade data from all supported networks is combined. Null asset addresses are normalized to chain-specific wrapped native assets by joining with wrapped native asset dimensions. Trades are enriched with actual user addresses from transaction `from_address` fields. Business line classification is applied to distinguish between Exchange AMM trades (using pre-defined trading pairs) and DEX Aggregator trades (using general asset lookup).
- **Key fields**: `chain`, `business_line`, `market_sector_id`, `business_segment_id`, user addresses, and asset information

### Component C: Data quality filtering

- **Purpose**: Problematic trades that could skew the trade count due to data quality issues are removed.
- **Logic**: Two levels of filtering are applied to the consolidated trade dataset. First, trades from denylisted trading pairs with limited price feed support are excluded. Second, trades involving denylisted assets with low liquidity or unreliable price data are removed. This filtering ensures that only legitimate, well-supported trading pairs contribute to the trade count.
- **Key fields**: `account_address` and `token_address`

### Component D: Trade volume processing and validation

- **Purpose**: Raw trade data is converted to standardized USD values for trade validation.
- **Logic**: Trades are processed differently based on the business line. For Exchange AMM trades, pre-configured trading pair decimals are used. For DEX Aggregator trades, asset decimals are retrieved from general asset metadata. Raw asset amounts are normalized by decimal precision. Normalized amounts are joined with end-of-day price feeds to convert asset amounts to USD values. Anti-manipulation logic is applied by selecting the minimum USD value between the two assets in each trade, which helps filter out trades with manipulated prices.
- **Key fields**: `token0_amount`, `token1_amount`, and `trading_volume`

### Component E: Final aggregation

- **Purpose**: Trade counts are aggregated on a daily level per chain and business segment.
- **Logic**: Processed and validated trade data is aggregated. Trades are grouped by daily boundaries using UTC day boundaries. Within each daily, chain, and business segment grouping, distinct transaction hashes are counted to determine the number of unique trades. Zero-filling is applied to ensure no missing days in the final dataset, and chain availability filters are applied to restrict output to supported networks.
- **Key fields**: `timestamp`, `chain_id`, `business_segment_id`, and `trade_count`

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

Number of trades executed on a decentralized exchange.

1inch1INCH

Trade count

Trade count

Competitive landscape

Chain breakdown