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 Liquidity turnover Methodology

## 1. Overview

Liquidity turnover is measured as the ratio of trading volume to total liquidity on Native Relay. This metric is utilized to indicate how efficiently deposited liquidity is used to facilitate trades across the protocol's pools. A higher turnover ratio is interpreted as efficient capital deployment, whereas a lower ratio indicates underutilized liquidity. The calculation is performed by dividing daily trading volume by the total value locked (TVL).

## 2. Data sources

- **Blockchain events**: `RFQTrade` events from `NativeRFQPool` contracts, and `SharesMinted`, `SharesBurned`, and `YieldDistributed` events from `NativeLPToken` contracts, covering Ethereum, Arbitrum, Base, BNB Chain, and 3 other chains
- **External data**: End-of-day price feeds and asset metadata used for decimal normalization and USD conversion

## 3. Step-by-step calculation

### Component A: Trading volume calculation

- **Purpose**: Trading volume is calculated to capture the total USD value of RFQ trades filled against the protocol's inventory.
- **Logic**: `RFQTrade` events are parsed from `NativeRFQPool` contracts across all deployed versions. For each trade, the asset addresses and raw amounts for both the seller asset and buyer asset are extracted. Orders forwarded by the router to third-party venues (which emit `ExternalSwapped` events) are excluded from the volume calculation. Raw amounts are normalized by decimal precision using asset metadata and converted to USD using end-of-day price feeds. The final trading volume for each transaction is determined by taking the smaller USD value of the two trade legs (the asset paid versus the asset received) to prevent double-counting, and then aggregated daily.
- **Key fields**: `sellerTokenAmount`, `buyerTokenAmount`, `sellerToken`, `buyerToken`

### Component B: Total value locked (TVL) calculation

- **Purpose**: Total value locked is calculated to determine the total liquidity available in the protocol.
- **Logic**: Depositor balances are tracked by aggregating `SharesMinted` (deposits), `SharesBurned` (withdrawals), and `YieldDistributed` (yield) events from `NativeLPToken` contracts. Because the LP token rebases, distributed yield is captured from protocol accounting events rather than token transfers. Market maker inventory is determined by extracting the positive balances of market makers' assets held in the vault. These two components are tracked in separate ledgers to prevent overlap, normalized by decimal precision, converted to USD using end-of-day price feeds, and summed to calculate the daily TVL.
- **Key fields**: `underlyingAmount`, `yieldAmount`, `position_raw`

### Component C: Liquidity turnover calculation

- **Purpose**: The final liquidity turnover ratio is calculated.
- **Logic**: Daily trading volume is divided by daily total value locked. Zero values are handled by nullifying the inputs to prevent division by zero, and the final metric is zero-filled for days without activity.
- **Key fields**: `trading_volume`, `tvl`

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

Trading volume divided by total liquidity.

Native

Liquidity turnover

Liquidity turnover

Competitive landscape