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

## 1. Overview

Active users (monthly) measures the number of unique addresses that make a revenue-generating transaction with a project, i.e. An application or a blockchain. For Native, unique transaction signers who initiate Request for Quote (RFQ) trades through Native Relay are identified and aggregated. This metric is utilized to evaluate user adoption and transaction activity across the protocol's deployed pool contracts. Active users (monthly) are measured over a 30-day rolling window.

## 2. Data sources

- **Blockchain events**: `RFQTrade` events from `NativeRFQPool` contracts, combined with transaction signer data from native chain transactions, covering Ethereum, Arbitrum, Base, BSC, and 3 other chains

## 3. Step-by-step calculation

### Component A: Trade event extraction

- **Purpose**: Extraction of RFQ trade events from the protocol's deployed pool contracts.
- **Logic**: `RFQTrade` events are parsed from `NativeRFQPool` contracts across the protocol's deployed pool contracts. For each trade, the transaction hash, block timestamp, and contract address are extracted to identify valid RFQ fills settled against the protocol's inventory.
- **Key fields**: `transaction_hash`, `block_timestamp`, `address`

### Component B: Transaction signer identification

- **Purpose**: Identification of the actual user address initiating each trade.
- **Logic**: The extracted trade events are joined with native blockchain transaction records using the transaction hash. The transaction signer address is extracted to represent the active user. This process ensures that the actual trader is captured, even when trades are routed through intermediary settlement contracts.
- **Key fields**: `transaction_hash`, `from_address`

### Component C: Monthly aggregation

- **Purpose**: Calculation of the monthly count of unique active users.
- **Logic**: The identified user addresses are aggregated over 30-day rolling windows based on the block timestamp. Duplicate addresses are removed within each 30-day rolling window, and the distinct count of active users (monthly) is calculated for each chain and product.
- **Key fields**: `block_timestamp`, `user_address`

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

Unique revenue-generating users over a rolling 30-day window.

Native

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown