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 Active users (monthly) Methodology

## 1. Overview

Active users (monthly) is calculated as the number of unique addresses that perform a revenue-generating transaction with 1inch over a 30-day rolling window. Trading activity is tracked across the protocol's DEX aggregation and exchange AMM services. This metric is utilized to evaluate user engagement, protocol adoption, and overall network activity.

## 2. Data sources

- **Blockchain events**: `Swapped` events from `Mooniswap`, `OneInchExchange`, and `AggregationRouterV3` contracts, `OrderFilled` and `OrderFilledRFQ` events from `AggregationRouterV5` and `AggregationRouterV4` contracts, various swap and order-filling function calls from `AggregationRouter` (versions V1 to V6) contracts, and transaction sender records, covering Ethereum, BSC, Polygon, Gnosis, Base, and 6 other chains
- **Reference data**: Wrapped native asset mappings, denylisted trading pairs, and denylisted assets

## 3. Step-by-step calculation

### Component A: Chain-specific trade extraction

- **Purpose**: Extract and standardize trading activity from 1inch contracts on each supported blockchain
- **Logic**: For each supported chain, trading data is collected from three source types. First, direct swap events such as `Swapped` are parsed from `Mooniswap`, `OneInchExchange`, and `AggregationRouterV3` contracts, with asset addresses, amounts, and user addresses extracted from event parameters. Second, function call traces are captured from various swap and order-filling functions across router versions V1 to V6. Third, for functions that do not emit asset denominations, function calls are joined with token transfer events using matching timestamps, transaction hashes, and amount values to identify the traded assets. Null addresses (representing native assets) are converted to chain-specific wrapped native assets using a reference mapping table.
- **Key fields**: `block_timestamp`, `transaction_hash`, `user_address`, `token0_address`, `token1_address`, `chain`, `business_line`, `version`

### Component B: Trade consolidation and filtering

- **Purpose**: Combine all chain-specific trades into a unified dataset with quality controls
- **Logic**: All chain-specific trade facts are unioned into a single table. A join with blockchain transaction records is performed to standardize user identification by using the transaction sender address (`from_address`) as the canonical user address rather than event-specific user fields. Denylist filters are applied to exclude specific problematic contract addresses and assets with limited price feed support. Trades involving denylisted assets on either side of the swap are filtered out.
- **Key fields**: `user_address`, `token0_address`, `token1_address`, `chain`

### Component C: Monthly user aggregation

- **Purpose**: Count distinct users per 30-day window with dimensional attributes
- **Logic**: The `block_timestamp` is truncated to day-level granularity. Trades are grouped by 30-day window and chain, and all users are classified under the 'Trader' user type. Distinct `user_address` values are counted per group to identify unique active users (monthly). Market sector, business segment, and product identifiers are extracted for dimensional analysis. Chain availability filters are applied to respect data availability windows for each blockchain.
- **Key fields**: `timestamp`, `chain`, `user_type`, `product_id`, `user_address`

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

1inch1INCH