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 Fees Methodology

## 1. Overview

The total value paid by users as spreads and fixed transaction fees on Variational Omni is measured by the Fees metric. This metric is utilized to reflect the total economic value generated by the protocol before any revenue-sharing allocations are applied. While a portion of the collected spreads is retained by the protocol treasury, the remainder is distributed to the external entity operating the liquidity vaults. Overall trading volume and economic activity facilitated by the platform are evaluated through the tracking of these fees.

## 2. Data sources

- **Blockchain events**: `PoolCreated` events from `SettlementPoolFactory` contracts, and ERC-20 `Transfer` events, covering Arbitrum
- **External data**: End-of-day price feeds and asset metadata for USDC

## 3. Step-by-step calculation

### Component A: Settlement pool identification

- **Purpose**: Identification of valid settlement pools to isolate fee-related transfers
- **Logic**: `PoolCreated` events from `SettlementPoolFactory` contracts are parsed to extract pool addresses. This step is performed to ensure that only transfers originating from official settlement pools are classified as fee inflows, preventing unrelated treasury transfers from being counted.
- **Key fields**: `pool_address`

### Component B: Treasury transfer extraction and classification

- **Purpose**: Capture and categorization of USDC transfers from settlement pools to the protocol treasury
- **Logic**: ERC-20 `Transfer` events are filtered for USDC transfers originating from the identified settlement pools and sent to the protocol treasury address. These transfers are classified into two categories based on their raw amounts: transfers matching a specific modulo and cap are classified as fixed deposit or withdrawal fees, while all other transfers are classified as spread-based fees.
- **Key fields**: `block_timestamp`, `token_address`, `amount`

### Component C: Take rate application and gross-up

- **Purpose**: Reconstruction of the total user-paid spread from the protocol's share
- **Logic**: An effective-dated take rate dimension is maintained to represent the protocol's share of the trading spread. The spread-based treasury inflows are grossed up by dividing the daily transfer amounts by the applicable take rate for that date. Fixed deposit and withdrawal fees are excluded from this gross-up and are added directly to the grossed-up spread to calculate total fees.
- **Key fields**: `take_rate`, `timestamp`

### Component D: USD conversion and aggregation

- **Purpose**: Normalization of fee values to USD and daily aggregation
- **Logic**: Raw USDC fee amounts are normalized by decimal precision using asset metadata and converted to USD using end-of-day price feeds. The daily values are aggregated with UTC day boundaries, and a series anchor is applied to initialize the historical data series at zero on the treasury launch date.
- **Key fields**: `timestamp`, `amount`

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

Total value users pay to use a protocol (gross fees, user-paid fees).

VariationalVAR

Fees

Fees

Competitive landscape