1

Excerpt from Compound's The Open Price Feed:

This is accomplished through a View Contract, which reads, parses, aggregates, transforms, etc from the storage contract. The determination of trustworthiness or quality of the data signed by reporters is a decision ultimately made in the View. Views may use a median price, an average, or whatever methodology they favor.

In what cases is an average oracle desirable? And a median one?

4
  • 1
    Neither. Your system will be front-run in both cases, since by the time the oracle price is updated in the blockchain, everybody already knows what the market price is. Sep 10, 2020 at 21:55
  • 2
    As with regards to "average vs median", which is a general issue in mathematics and finance (not specific to oracles), use median when the number of samples is very small in comparison with the range of samples. For example, if you have the 3 samples [10, 10^15, 10^30], then average will give you a result which is relatively very close to 10^30 (like, 3*10^29), where a median will give you 10^15. In a way, median is kinda like "geometric average" instead of "arithmetic average". Another way to look at it - median in this case is "the average number of digits". Sep 10, 2020 at 22:02
  • @goodvibration your comments make for a perfectly legit answer. Sep 11, 2020 at 11:39
  • 1
    Let me rephrase it, because it doesn't actually pinpoint the difference. The general goal of using a median here is to mitigate the impact of spikes. For example, suppose the samples are [10^1, 10^2, ..., 10^9, 10^30]. As you can see, the average here - greatly impacted by that spike, is 10^29. The median, on the other hand, is 10^5 or 10^6 (or something in between, depending on how you wanna handle an even number of samples). Sep 12, 2020 at 9:02

2 Answers 2

1

First of all, your system will be subjected to front-running in both cases, since by the time the oracle price is updated in the blockchain, everybody already knows what the market price is.

So you may want to consider using an oracle to begin with.

As with regards to "average vs median", which is a general issue in mathematics and in finance (not specific to oracles):

Within the context of your question, the general goal of using a median is to mitigate the impact of spikes.

For example, suppose the samples are [10^1, 10^2, ..., 10^9, 10^30] (not necessarily in that order).

As you can see, the average here - greatly impacted by that "10^30" spike - is larger than 10^29.

The median, on the other hand, is 10^5 or 10^6 (or something in between, depending on how you choose handle an even number of samples).

Thus, using a median in this specific scenario can help mitigating the impact of that "unusual" spike.

More generally, use median when the number of samples is very small in comparison with the range of the samples.

3
  • Shouldn't the median be between 10^15 and 10^16 instead of 10^5 and 10^6? Sep 14, 2020 at 18:09
  • @PaulRazvanBerg: No. Median is the middle value in the sorted list of values. In this case, the two values in the middle are 10^5 and 10^6. Sep 14, 2020 at 18:17
  • Whoops, I thought that the last item before the last in your list is 10^29. I now see you set it to 10^9. Makes sense, thanks. Sep 14, 2020 at 21:59
1

You want to use the median.

Using the average means that you trust all data providers (or it looks like reporters according to that article) equally. Having a bad data provider will always throw off your value, even if just a little.

Also goodvibrations makes some good points about sample size, given a massive number of samples it would be "better".

This is especially true if you're going to use a decentralized source like Chainlink with centralized sources like Coinbase or Uniswap (where uniswap the price depends on the liquidity). "Mixing" data quality by getting the mean doesn't make sense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.