Variational Docs
HomeDiscordTwitterBlog
  • Getting Started
  • What Is Variational
  • Why Build Variational
  • Core Contributors
  • Roadmap
  • Official Links
  • Variational Protocol
    • Overview
    • Key Concepts
      • P2P Trading Protocol vs DEX
      • Trading via RFQ
      • Variational Oracle
      • Settlement Pools
  • Omni
    • About Omni
    • The Omni Liquidity Provider (OLP)
    • Listing Engine
    • Getting Started with Omni
      • Authentication
      • Deposits
      • Withdrawals
      • Trades
    • Trading
      • Mark, Index, and Quoted Prices
      • Market vs. Limit Orders
      • Take Profit & Stop Loss
      • Open Interest & Funding Rates
      • Automatic Deleveraging / Counterparty Liquidation
      • Margin
      • Slippage
      • Leverage
      • Liquidation
      • Fully Diluted Valuation (FDV)
      • Risk Limits
      • Fees
  • Pro
    • About Pro
  • Technical Documentation
    • API
      • SDKs
      • Quickstart and Tutorials
        • API Trading Prerequisites and Setup
        • Settlement Pool Deposit Tutorial
        • Taker (RFQ Submitter) Tutorial
        • Maker (RFQ Responder) Tutorial
      • Endpoints
      • Data Models
      • Headers
      • Pagination
      • Rate Limits
      • Authentication
    • Contracts and ABIs
    • Security and Audits
    • Partners
  • Token
    • $VAR
  • More
    • Media Kit
    • FAQ
    • Getting Help (Support)
    • Additional Resources
  • Legal
    • Terms of Use
    • Privacy Policy
    • Restricted Persons
Powered by GitBook
On this page
  • Overview
  • The Listing Engine
  1. Omni

Listing Engine

Overview

On Omni, new perps markets are permissionlessly listed, which means that they are automatically listed once they fulfill certain criteria:

  • Price Feeds: There must be a suitable oracle to construct the index price from. This criteria can be fulfilled by having an exchange listing (e.g., on Coinbase) or an AMM pool (e.g., on Uniswap) with sufficient liquidity.

  • Minimum Activity Requirements: minimum market cap, 24h trading volume, and liquidity requirements.

  • Decentralization Requirements: no one holder of the token can be too large, and no group of holders can be too large as a % of the circulating supply.

  • Security Checks: we check the contract code to make sure there is no harmful code, including honeypots, transfer restrictions, etc.

Additionally, markets may be delisted if they fail to sustain the requirements. A delisting means all positions will be closed at the settlement price. The settlement price is an exponentially weighted moving average of the instrument price at the time of the delisting.

The Listing Engine

One of the largest challenges in building Omni has been sourcing data. Omni requires a huge amount of reliable and low-latency market information (such as price feeds) to support the hundreds of listings on the platform. To address this challenge we utilize a combination of many of data sources, including both direct exchange connections and independent data providers. This data is used to identify new CEX listings and newly minted tokens that may be viable listings.

For each new CEX listing / newly minted token detected by our data feeds, the listing engine runs a variety of market and security checks to determine whether a token is both active enough and safe enough to justify listing. Some examples of market checks include FDV, trading volume, number of holders, and rate of increase of holders. Examples of security checks include available liquidity, holder distribution, and an analysis of contract code. Each token that passes all of these checks is listed, while tokens that fail any check are not listed (at least until they fulfill all criteria).

Each asset on Omni is either listed as a CEX or DEX asset. While listing assets via CEX is often preferable due to deeper liquidity, new tokens are often only tradable on-chain before achieving CEX listings. If a token listed as a DEX asset achieves enough CEX listings, Omni will delist the DEX version of the token and list the CEX version.

Since the market and security checks ensure that each new asset is safe for OLP to trade, OLP begins quoting for each new market as soon as it is listed. While the market and security checks for delistings are slightly more lenient than initial listings (to avoid delisting churn), they ensure that Omni does not retain listings that are no longer active or liquid enough for OLP to safely quote a spread on.

The automated listing and delisting process is one of the most complex pieces of Omni. Since the stakes are high with listings and delistings, the listing engine is heavily audited and regularly monitored by our team to ensure proper behavior. While building and maintaining this system is complex, it allows Omni to often be the first place that new tokens obtain a perp listing.

PreviousThe Omni Liquidity Provider (OLP)NextGetting Started with Omni

Last updated 16 days ago