Native Relay streams Core prices to wallets and aggregators and routes their orders into Native, while Native Pro exposes the Core matching engine to institutions over direct, exchange-grade interfaces. Trades settle non-custodially through NativeRouter and CreditVault contracts deployed on each supported EVM chain. Native applies standard maker and taker fees on Native Core: 0% on stablecoin and softpeg markets, 0.1% taker and 0.02% maker on majors and RWAs, and 0.001% taker with 0% maker on selected markets. Integration partners routing through Native Relay negotiate a customized additional Relay fee, typically set at zero or minimal, on top of the standard maker and taker rates.

Native is a non-custodial trading infrastructure for on-chain spot markets that decouples pricing logic from asset settlement. Native Core is an on-chain sovereign state machine where price discovery and central limit order book matching are finalized, while Native Pool consists of distributed smart contracts on EVM chains that custody assets and enforce settlement. Rather than pricing trades through AMM pools, Native matches orders in its own engine and exports the resulting liquidity to integrating chains and distribution surfaces.

Native serves wallets, aggregators and intent platforms that route order flow into Native to source on-chain liquidity, institutions and professional market makers that integrate through Native Pro, and liquidity providers that supply the permissionless vaults used for settlement.

website

twitter

Exchanges (DEX)

Native

# Native Average trading volume (per user) Methodology

## 1. Overview

Average trading volume (per user) measures the average trading volume generated per unique user over a fixed 24-hour window for Native Relay. This metric is calculated by dividing the total daily trading volume by the number of active users (daily). It is utilized to evaluate user behavior and determine whether the protocol's volume is driven primarily by institutional participants (characterized by high average volume) or retail traders (characterized by lower average volume).

## 2. Data sources

- **Blockchain events**: `RFQTrade` events from `NativeRFQPool` contracts, and transaction sender data from native transaction tables, covering Ethereum, BNB Chain, Arbitrum, Base, and 3 other chains
- **External data**: End-of-day price feeds and asset metadata for traded assets

## 3. Step-by-step calculation

### Component A: Trade extraction and volume valuation

- **Purpose**: Extract RFQ trades and calculate the USD value of each trade
- **Logic**: `RFQTrade` events are parsed from `NativeRFQPool` contracts across the protocol's deployed pool contracts. For each trade, the seller asset amount and buyer asset amount are extracted. These amounts are normalized by decimal precision using asset metadata and converted to USD using end-of-day price feeds. The trading volume for each transaction is valued at the smaller USD value of the two trade legs (the asset paid versus the asset received) to prevent distortion from pricing discrepancies.
- **Key fields**: `seller_token`, `buyer_token`, `seller_token_amount`, `buyer_token_amount`

### Component B: Active user tracking

- **Purpose**: Identify and aggregate unique active users (daily)
- **Logic**: To identify the actual trader, transaction hashes from the extracted trades are joined with native blockchain transaction tables to retrieve the transaction signer address. The unique transaction signers are aggregated daily to calculate the active users (daily) for the protocol.
- **Key fields**: `transaction_hash`, `from_address`

### Component C: Average volume calculation

- **Purpose**: Calculate the average trading volume per user
- **Logic**: The total daily trading volume is divided by the active users (daily) to compute the average trading volume (per user). Daily granularity is maintained using UTC day boundaries, and any days with missing data are filled with zeros.
- **Key fields**: `trading_volume`, `user_dau`

## What is counted
Volume covers orders filled against the protocol's own pooled liquidity across the protocol's deployed pool contracts. Orders that the router forwards elsewhere for execution are excluded because whichever venue fills them settles and reports them. Every fill against the protocol's liquidity is counted, with no exclusion by counterparty, recipient, or trade size.

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

Average trading volume (per user)

Trading volume divided by daily active users.

Native

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape