In our current product, a contract can be closed at two different points in time and the quantity of ETH held on deposit will be redistributed to both parties according to the price evolution:

At the expiration date.

Before the expiration date, if the price goes too low or too high to protect both parties from insolvency.

Finding the right price that describes the current situation across the main ETH/USD exchanges is therefore crucial to our product. As the Ethereum white paper correctly identifies, the biggest challenge for financial derivatives is the elaboration of a “trusted source” on the blockchain for the ETH/USD price. This refers mostly to the challenge of building a trusted or decentralized oracle but the fairness or accuracy of this oracle source is an essential aspect.

As we aim to create fair products and help our users to have some intuition on how our price feed evolves in relation to the different individual prices on the exchanges, our price feed needs to be a descriptive statistic of all major exchanges but not too sensitive to recent volatilities on one particular exchange.

Four Platforms, Four Prices?

The graph below shows Ether prices for September 19th, 2017, starting at around 1pm and ending at around 1pm the next day. There is approximately a point every 300ms, resulting from asynchronous requests on web APIs of Gdax, Bitfinex, Gemini and Kraken.

There are differences in prices among platforms that can possibly be explained (not exclusively and/or exhaustively) by:

Specific characteristics of the exchange : users profile and localisation, risk premium that may reflect trust in the exchange and its solvability…

: users profile and localisation, risk premium that may reflect trust in the exchange and its solvability… Lack of arbitrage trader : Ether should not cost a different price across each exchange. Arbitrage simply brings the exchanges together to an average price. As ether’s market grows, the gap between exchanges will narrow, as the rate at which people arbitrage increases.

: Ether should not cost a different price across each exchange. Arbitrage simply brings the exchanges together to an average price. As ether’s market grows, the gap between exchanges will narrow, as the rate at which people arbitrage increases. Lack of liquidity: in one of the platform (also a consequence of lack of arbitrage trader).

In addition to price differences among platform, we noticed a difference in behaviour between Kraken and the other three platforms. We noticed that Kraken exhibits 2 to 6 times higher volatility levels than its peers. This is not obvious on the graph above but can be more apparent from time to time for example on August 4th.

Gdax, Bitfinex, Gemini and Kraken’s Prices on 4th August

We explain this difference by the existence of dark pools on Kraken. The Kraken dark pool is an order book not visible to the rest of the market, in which each trader only knows their own orders.

How to Aggregate Them?

Our objective was to build a robust price feed but not too sophisticated. Indeed, our price feed needs to be easily understandable to be trusted. In this regard, we believe that a highly sophisticated price feed wouldn’t add any value to our product.

We wanted a price feed that :

Is not too sensitive to outliers

Handles Kraken’s specifics

Takes into account each platform’ volume and thus the adequate weight that should be given to its current price

It requires three steps:

We spot outlier prices using typical statistical tools and don’t take them into account when computing our price feed. Moreover, if one platform stops responding, we replace its price by the last price available but only if it is not older than one minute. Otherwise, we exclude the platform from our computation until it comes live again. This aims at avoiding artificial spike or drop in our price feed if one platform stops responding temporarily thus affecting the final price feed computation. We smooth Kraken’s price by using a moving-average filter if necessary. The moving average filter is a widely used indicator that helps smooth out prices by filtering out the “noise” from random price fluctuations. We then use Kraken’s smoothed price in our calculation.

Illustration of a moving average smoothing on Kraken

Below is an illustration of a smoothing on Kraken on August 4th using a moving average of 20 minutes to obtain a price at current time. It is not an optimal time length and not the one we are using but it was chosen for illustration purposes.

20 min Moving Average Filter Kraken’s

We choose our time length so that the volatility of Kraken’s Moving Average is in line with the other platforms’ volatility. Currently, we use a 10 seconds moving average but this is subject to changes. After applying a 10 seconds moving-average to Kraken’s price, we obtain the following volatility levels as of September 20th:

We are conscious of the fact that this filtering technique has some limitations. It might not always be relevant especially if there is a change in Kraken’s behavior and thus should be closely monitored and adjusted and even cancelled if necessary.

3) Finally, we use a volume-weighted average price, meaning we average the price of each platform weighted by the volume traded on the platform over a particular time horizon (usually 24 hours). For example, given the current volumes (as of September 20th), the weight would be :

VariabL Price Feed in a nutshell

All in all, we obtain a price feed that we believe is robust, parsimonious and representative for the main ETH/USD exchanges.

It has the following properties:

It doesn’t take into account outliers

It is not sensitive to any platform’s momentary blackout

It handles Kraken’s specifics

It takes into account platforms’ volume, thus the pertinence of the price provided

It has volatility levels in line with other platforms’ volatilities. As of September 20th :

It is the purple line displayed on the graph below.

VariabL Price Feed

We plan to set our Pricefeed As A Service (PaaS) and potentially open source it to other projects and developers. In the future, dApps could use our API as a reference and serve as an oracle.

We are looking forward to making it functional and opening it to the community. Meanwhile, let us know what you think of our Price Feed model and feel free to contact us on slack if you want to discuss more.