# Pricing Methodology

Derivation of prices within the GRVT protocol.

## Overview

Oracle data feeds provided by Block Scholes are completely and verifiably trustless, through the use of EIP712 cryptographic signatures. This means GRVT smart contracts can always ensure the data has not been tampered with, and is genuinely as attested by Block Scholes as a regulated & independent 3rd party provider.

GRVT offers the following prices via our Market Data endpoint.

**Mark Price**Mark price is the fair, and authoritative price of a derivative contract on GRVT.

GRVT uses it to compute margin requirements, vault balance, and liquidation eligibility.

It is supplied by a third-party oracle to ensure that GRVT has no way to manipulate mark prices.

As GRVT is a hybrid exchange (HEX), mark prices are trustless similar to other DEXes.

**Index Price**Index price is the aggregate derivative contract price sourced from leading CEXes.

GRVT uses it as a reference price to trigger temporary trading halts on our order book.

**Mid Price**Mid Price is the average of the best bid and best ask prices on our order book.

GRVT uses it to adjust GRVT’s mark price closer to pre-trade prices on our exchange.

When it diverges too far from the index price, GRVT triggers a trading halt on our order book.

**Last Price**Last Price is the last transacted price of a derivative contract on GRVT.

GRVT uses it to adjust GRVT’s mark price closer to post-trade prices on our exchange.

**Settlement Price**All standard options and futures on GRVT are settled at 8am UTC on the expiration date.

The settlement price will leverage a highly precise spot index price.

Both **Mid Price** and **Last Price** are fairly trivial and standardised concepts, so this document will not go into deeper detail about these prices.

## Price Sources

These are the price sources used to compute GRVT’s Index Price and Mark Price.

### Spot/Futures/Perps (TBC)

Binance

OKX

Bybit

Deribit

### Options

Deribit

OKX

Bybit

## Index Price

The `index_price`

for all derivatives is simply the VWAP of `mid_prices`

retrieved from our source exchanges.

All index prices are delivered at `200ms`

frequency on our Market Data endpoints.

## Settlement Price

`index_price`

and `settlement_price`

are highly similar. They both leverage VWAP of `mid_prices`

.
The only difference is:

`index_price`

trades away accuracy for responsiveness.`index_prices`

are always published at the`200ms`

mark.It will perform a VWAP over the latest

`mid_prices`

obtained from each exchange.If an exchange is late to publish its price,

`index_price`

will not wait for the latest price, and simply work off the previously published price.

`settlement_price`

trades away responsiveness for accuracy.`settlement_price`

is based on TWAP price over 15 minutes before the expiration time 8am UTC of each exchange.There may be up to several seconds of delay for

`settlement_price`

to come through.But it is guaranteed to be always highly precise and accurate.

`settlement_price`

always TWAPs over `spot_prices`

, since all options and futures are settled based on `spot_price`

.

## Mark Price

Mark Prices are computed using the below formula:

This equation introduces three new concepts. Ignore `theoretical_price`

for now, simply assume that there exists a fair, accurate, and responsive `theoretical_price`

for each and every derivative contract traded on GRVT. We will get to it in a later section. We will first focus on the `EWMA`

components.

Note that all the computations shared in this section are performed by a third-party oracle, and signed by the oracle’s private key. GRVT has no way to manipulate the mark prices on our smart contracts.

### Mark Price Adjustments

The purpose of the `pre_trade_ewma`

and `post_trade_ewma`

components are to adjust the `theoretical_price`

such that we yield a `mark_price`

that is fine-tuned towards both the pre-trade `mark_price`

and the post-trade `last_price`

that are occurring on our exchange.
Variables such as the settlement currency, margin model, and liquidity would cause the `theoretical_price`

(that is aggregated from various exchanges) to diverge slightly from the trading activity on the GRVT order book. These mark price adjustments help to account for those differences, and yield a mark price that is calibrated towards the GRVT order book.

Take note that:

GRVT’s

`EWMA`

components track price differences between`mid_price`

and`theoretical_price`

`last_price`

and`theoretical_price`

Price is a fast-moving metric, whereas price difference is a slow-moving metric.

i.e. If a perpetual on our exchange consistently trades $5 above

`theoretical_price`

, likely, this price differential will not fluctuate wildly from moment to moment.

EWMA is a lagging/stable indicator, and is generally not highly responsive.

It is more desirable to apply it towards slow-moving metrics than towards fast-moving metrics.

EWMA, when used to track price differences, is resilient against adverse conditions

If there are no quotes in the order book,

`pre_trade_ewma`

simply does not update.If there is no trading activity,

`post_trade_ewma`

simply does not update.The price differences continue to be stable, and accurate.

This quality of EWMA makes it more suitable for tracking price differences on naturally illiquid instruments (options) compared to time-bound indicators such as 5-minute moving averages.

Given the assumption that the

`theoretical_price`

is fair, accurate, and responsiveUsing EWMA to track price differences always yields responsive prices that are well adjusted towards GRVT’s order book.

### EWMA

EWMA (Exponentially Weighted Moving Average) is a lagging/stable indicator that applies more weight towards recent values, and less weight towards less recent values. It is a lagging indicator that is appropriate for placing more bias towards more recent values.

A standard EWMA formula is as follows:

**Alpha: **$\alpha$

$\alpha$ is a weight

The higher the $\alpha$, the more the EWMA adjusts to recent prices.

**Value: **$r_t$

$r_t$ is the value that we are tracking.

$r_t$

`= (last_traded_price OR book_mid_price) - theoretical_price`

### Pre-Trade EWMA

Where

$\alpha$= 0.002

$r _t$

`= (mid_price - theoretical_price)`

Rationale for $\alpha$ `= 0.002`

:

GRVT publishes tickers every

`100ms`

Over a 1 second period, there are 10 ticker updates

The last 1 second of values will make up

`2%`

of the EWMA (`1-(0.998)^10`

)

Over a 1 minute period, there are 600 ticker updates

The last 1 minute of values will make up

`70%`

of the EWMA (`1-(0.998)^600`

)

Over a 5-minute period, there are 3000 ticker updates

The last 5 minutes of values will make up

`99.8%`

of the EWMA (`1-(0.998)^3000`

)

When the order book is empty,

`mid_price`

will take on a null value, and the EWMA is not updated.

### Post-Trade EWMA

Where

$\alpha$=

`config_weight * min(last_notional/config_notional, 1)`

`config_weight = 0.1`

`config_notional = $1000`

$r _t$

`= (last_price - index_price)`

Rationale for `config_weight = 0.1`

:

The largest amount a single large trade can affect our EWMA is by

`0.1`

This limits the impact of large trades on our EWMA

The last 10 trades will maximally make up

`65%`

of the EWMA (`1-(0.9)^10`

)The last 20 trades will maximally make up

`88%`

of the EWMA (`1-(0.9)^20`

)The last 50 trades will maximally make up

`99.5%`

of the EWMA (`1-(0.9)^50`

)When there is no trading activity, the EWMA is not updated.

Rationale for `config_notional = $1000`

:

We do not want multiple small trades to affect our EWMA too much

Trades that are lower than

`config_notional`

will have linearly less impact on EWMA.A trade of

`$500`

will only make up`5%`

of the EWMAA trade of

`$200`

will only make up`2%`

of the EWMA

## Theoretical Price

The above mark price adjustments are only useful when applied onto a fair, accurate, and responsive `theoretical_price`

. GRVT will leverage the following methodologies to compute theoretical prices for all derivative contracts traded on our exchange.

### Perpetuals

The `theoretical_price`

for perpetuals is simply its `index_price`

. Given the high liquidity and trading volume of perpetual contracts, GRVT is able to retrieve a fair, accurate, and responsive `theoretical_price`

with relative ease.

All perpetual `mark_prices`

are delivered at `200ms`

frequency on our Market Data endpoints.

### Futures

While GRVT can simply adopt the same heuristic for futures, it would limit GRVT’s long-term ability to provide custom-dated futures that are not traded on other exchanges. Instead, GRVT uses a `forward_price`

as the `theoretical_price`

.

See: Forward Price: Definition, Formulas for Calculation, and Example

The `index_prices`

of future contracts are reverse-engineered into a risk-free rate curve. This risk-free rate curve is then applied on the `index_price`

of the underlying asset to yield a `forward_price`

.

This `forward_price`

will almost always be identical to the futures `index_price`

given that they are computed from the same source. It is, however, free from risk-free rate arbitrage, and may differ from time to time when such arbitrage opportunities exist. It also has the benefit of providing 100% uptime. Even in the event that an illiquid futures order book goes dark, the `forward_price`

continues to be up. The risk-free rate curve is smoothed over time using EWMA as well.

All futures `mark_prices`

are delivered at `200ms`

frequency on our Market Data endpoints.

The risk-free rate curve is re-calibrated every `20s`

, but not a huge issue given that it is a slow-moving metric.

`forward_prices`

are always highly responsive to spot price movements.

### Options

Relying on the options `index_price`

directly is typically a bad idea. Given that:

Options order books typically have large spreads

Options prices are typically highly volatile

Options order books are very frequently lacking any liquidity whatsoever

This is especially true for deep ITM/OTM options or options with longer term

As such, GRVT derives an option’s `theoretical_price`

using the Black-Scholes model and uses three market indicators as input:

spot price

risk-free rate

implied volatility

The first two indicators have already been explained in the futures section. So let’s skip that and only focus on implied volatility.

Firstly, note that options price is a fast-moving metric and is not very suitable to be smoothed across time. However, implied volatility is a slow-moving metric and can benefit from time-based smoothing without serious loss of accuracy or responsiveness. This makes implied volatility much safer to rely on for options `theoretical_price`

given the frequent outages of options order books.

GRVT’s IV Surface is built as follows:

Options

`index_prices`

are collectedITM options prices are removed from consideration given their large spreads and low liquidity

This is safe to conduct given the call-put parity equation

The OTM prices on the other side can be used as a more reliable substitute

SVI parameters for the IV surface are then derived from the OTM options prices

This surface “fills in the gap” whenever specific

`mid_prices`

are missing from the order book

The IV surface is smoothed over time using EWMA

This yields a high-uptime IV surface that is resilient against order book outages

This also yields an arbitrage-free IV surface that is highly suitable for

`theoretical_price`

This IV surface is re-calibrated every `20s`

similar to the situation with risk-free rate curves.

Lastly, by combining

A spot

`index_price`

that is naturally fair, accurate, and responsiveA risk-free rate that is smoothed over time, and is a slow-moving metric

An implied volatility that is smoothed over time, and is a slow-moving metric

GRVT is able to yield a fair, accurate, and responsive options `theoretical_price`

that has 100% uptime.

All options `mark_prices`

are delivered at `500ms`

frequency on our Market Data endpoints.

The IV surface is re-calibrated every `20s`

, but not a huge issue given that it is a slow-moving metric.

Options `theoretical_prices`

are always highly responsive to spot price movements.

Last updated