Omni charges zero explicit trading fees; the user's cost is the bid-ask spread OLP quotes. Variational's revenue is a share of that spread, swept from settlement pools into a protocol treasury wallet, with the remainder retained by OLP.

Users request a quote and OLP, Variational's in-house market maker, is the sole counterparty on Omni; trades are priced, agreed, and booked off-chain, with the chain holding only USDC collateral. Each user is deployed a bilateral settlement pool by a factory contract, and every state-changing function is oracle-gated, so an off-chain operator drives settlement.

Variational is an RFQ perpetuals venue on Arbitrum. Its consumer app, Omni, lets users trade perpetual futures against the protocol's own market maker, OLP.

twitter

website

github

Derivative exchanges

Variational

# Variational Revenue Methodology

## 1. Overview

Revenue measures the portion of fees that Variational retains in its treasury. Because trades on Variational Omni are priced and settled off-chain, individual trade fees are not emitted via on-chain events. Instead, the protocol's share of trade spreads and fixed fees is captured when USDC is transferred from settlement pools to the protocol treasury. The actual treasury inflows generated by the protocol before operating expenses are represented by this metric.

## 2. Data sources

- **Blockchain events**: `PoolCreated` events from `SettlementPoolFactory` contracts and ERC-20 token transfers on Arbitrum
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Settlement pool identification

- **Purpose**: The identification of valid settlement pool addresses to filter out non-fee transfers.
- **Logic**: `PoolCreated` events from `SettlementPoolFactory` contracts are parsed to extract a list of active settlement pool addresses. This list is used to ensure only transfers originating from official settlement pools are processed.
- **Key fields**: `pool_address`

### Component B: Treasury transfer extraction

- **Purpose**: The extraction of USDC transfers from settlement pools to the protocol treasury.
- **Logic**: ERC-20 token transfers are filtered to isolate USDC transfers where the sender is an identified settlement pool and the recipient is the designated protocol treasury address.
- **Key fields**: `block_timestamp`, `token_address`, `amount`, `from_address`, `to_address`

### Component C: Fee classification

- **Purpose**: The classification of transfers into fixed fees and spread-based fees.
- **Logic**: Transfers are categorized based on the transfer amount. Transfers that are exact multiples of 100,000 units (up to a cap of 200,000,000 units) are classified as fixed fees, which represent deposit and withdrawal fees. All other transfers are classified as spread fees.
- **Key fields**: `amount`, `fee_type`

### Component D: USD conversion and normalization

- **Purpose**: The normalization of transfer values and conversion to USD.
- **Logic**: Transfer amounts are normalized by decimal precision using asset metadata. The normalized amounts are then multiplied by end-of-day price feeds to determine the USD value of each transfer.
- **Key fields**: `amount`, `price_usd`

### Component E: Revenue aggregation

- **Purpose**: The aggregation of daily treasury inflows to calculate total revenue.
- **Logic**: The USD values of both fixed and spread fee transfers are summed by day. Revenue is defined as the total USD value of these treasury inflows. A series anchor is applied to initialize the revenue metric at zero starting from the treasury launch date.
- **Key fields**: `revenue`

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

VariationalVAR

Revenue

Revenue

Competitive landscape