Comment on page

Pricing (Oracles)

Reference and indexed price feeds for Vertex markets.
Oracles play a crucial role in a decentralized exchange (DEX), functioning as the pathway for Vertex’s on-chain contracts to access existing data sources (e.g., prices) off-chain and execute advanced computations on-chain. Vertex’s high-performance exchange design requires an oracle architecture developed for ultra-low-latency and robust oracle feeds across the long tail of market pairs.
On a performant DEX, oracles need to deliver price feeds for each market on the exchange with several core properties, including:
  • Decentralized
  • Robust
  • Low-Latency
  • Cost-Efficient
Price feeds for various exchange assets help calculate intricate functions, including account collateralization, perpetual funding rates, and more. Oracle price referencing also needs to maintain redundancy across data publishers, meaning that data feeds are defensible to stale prices from reference providers (e.g., third-party exchanges) and can operate without a single point of failure.
Vertex uses Stork Oracle as its decentralized oracle provider.
Stork is an ultra-low-latency, decentralized, hybrid oracle network for EMV-compatible price feeds.
Stork’s oracle architecture prioritizes performance, congruent with Vertex’s low-latency order-matching and emphasis on CEX-grade execution speeds. Using ultra-fast WebSockets across multiple regions and node providers, Stork can ensure that Vertex’s reference prices are available on the millisecond level, comparable to the data velocity used on CEXs and TradFi exchange venues.
Stork also empowers Vertex with its hybrid on/off-chain architecture, unlocking the ability to perform initial processing off-chain and subsequently push price updates on-chain specific to each product – such as perpetuals.
With the Vertex sequencer, price updates are bundled off-chain with each sequence of actions submitted before being pushed on-chain, enabling continuous reference prices at lower costs and computational complexity. This is necessary for a performant DEX relative to other, pure on-chain oracle providers that push price updates less frequently[1].
Scarcer price updates in pure on-chain oracle models reduce the ability to support long-tail assets where gas fees are not justified relative to the on-chain demand for the corresponding asset. Less frequent price updates also do not function as effectively as hybrid on/off-chain oracle models amid significant market volatility.
With Stork, Vertex can achieve robust, low-cost, and high-performance price referencing and correlated on-chain calculations (e.g., perpetual funding) while minimizing pricing vulnerabilities across the long tail of assets.
Please refer to their documentation here for more information on the Stork oracle architecture.

Vertex & Stork Oracle Architecture

Stork publishers and data sources are chosen for their ability to provide low-latency price updates reliably. The methodologies are chosen to enable Stork clients to achieve specific results and will evolve over time.
Each publisher can contribute an index price for the markets supported by Stork. Currently, implementing the index calculation is at each publisher’s discretion; ergo, not every publisher will converge their price.
On Vertex, three different Oracle price feeds exist via Stork, all of which are instantaneous per market. These include:
1.Spot Oracle Prices (spot on centralized exchanges): The spot oracle prices from Stork comprise an index of the reference spot exchanges to price against Vertex perpetual products using a TWAP of the index price across the Median of the Last Trade Price from supported exchanges. Supported exchanges (exchanges with major USD or BUSD markets):
  • Binance
  • Coinbase Pro
  • Kraken
2. Perpetual Prices (centralized exchanges): Continuous LP-based perpetual prices; these serve as the reference prices for calculating funding for the perpetual futures. A closed-loop funding rate option is used, where both the exchange’s (i.e., Vertex's) own mark price and the spot index price TWAPs are captured by Stork, reducing centralization and the cost of storing and computing the funding fee on-chain.
The Vertex Perpetual Index price is a volume-weighted perpetual price across supported exchanges, converted from USDT to USD using a volume-weighted average of USDC-USDT and BUSD-USDT spot markets.
  • Exchanges: Binance, ByBit, OKX.
  • Markets: Markets quoted in USDT and converted to USD using volume-weighted spot prices for USDC-USDT and BUSD-USDT markets.
  • Volume: Trailing four (4) hours trailing volume for each perpetual market.
3. Orderbook Price on Vertex.
For liquidations, Vertex uses the Spot Oracle Price (#1) and the Perp Oracle Price (#2) to calculate a trader's account value. You can find the liquidation calculations here.
For funding, Vertex uses a TWAP of the Orderbook Price on Vertex (#3), known as the mark price, and a TWAP of the Spot Oracle Price (#1). More details on the funding rate calculations can be found here.
For an in-depth description of the Liquidation calculations, please refer to the Basics – Liquidations section.
Unlike the index price, every Stork publisher follows the same calculation for the perpetual index price.
  • Funding Rate Calculations: The spot index price and Vertex’s perpetual contract price (e.g., mark price) calculate the funding rate.
  • Calculating Liquidations: The spot oracle price is used for liquidations. You can find the liquidation calculations here.
For liquidations, the Spot Oracle Price is what's utilized for liquidations and displayed on the Vertex front-end.
An independent oracle price also exists for USDC, which will allow for functional health calculations and trading behavior even in the case of USDC de-pegging.
The Vertex front-end will always display prices quoted against USDC (NOT USD), and there are NO assumptions within the protocol where 1 USDC = 1 USD.
Vertex removes the ability to submit relative orders, where trades are executed when the market price deviates X amount from the oracle price. This is because it significantly reduces complexity, and the use case of relative orders is niche.
  1. 1. ↑