Case Study — Volatility Insurance with a decentralized oracle system

Tl;dr — This one is for the technical reader who’s interested in decentralized oracles. I will take a financial instrument I refer to as , and will show how you could go about integrating it with a decentralized oracle system in a way that keeps it safe from manipulation. I would argue that decentralized oracles should be integrated to smart contracts and financial instruments in this way of boutique handcrafting, including specially chosen distance functions and parameters, and not by an all around approach offered by systems such as , and others.

To summarize our logic, we added a decentralized oracle component to the Volatility Insurance instrument. The decentralized oracle is responsible for the ETH/USD price feed. Every ETH Holder may place an anonymous bet on the current ETH/USD price. They are then weighted-averaged by the bet sums. This serves as the price feed without any further checks or limitations. The betplacers are then compensated according to how close their bets were to the weighted average, as we would want in a . Compensation to the decentralized oracle system is derived by commissions on the volatility insurance positions. When a dishonest oracle tries to manipulate the price feed, he will earn compensation in his volatility insurance positions as the price will be skewed. We have analyzed the case of an oracle opening many positions as the insurer. On the other hand, he loses compensation in the oracle system as he’s off from the honest reporters average. When the compensation lost in the oracle system is greater than that gained in the volatility insurance positions, there is no incentive for oracles to act dishonestly. What we came up with is a property that if the system satisfies, it should be safe from dishonest bets placed by oracles. Note that different leverage levels will require different constraints on the decentralized oracle system. What we mainly control is α, which we can increase it by increasing commission rates. We also choose the oracle compensation function. My goal in this quick math analysis was to illustrate a few things:

• Integrating a financial instrument with a decentralized oracle system is not an out of the box task. I did these calculations because I haven’t seen anywhere online where this is done. All stable coins I revisited were only vaguely talking of future integration, and all decentralized oracle systems are built agnostically to any concrete financial instrument, which I find disturbing. It’s hard for me to believe you can make a ‘one size fit all’ system for this issue.
• Even in this minor example, commission rates would change across oracle compensation functions, different ε thresholds, different safety margins against dishonest insurer capabilities and different volatility insurance leverages. With a different financial instrument, the equations will look totally different — so how can the same decentralized oracle system work for it ?
• I don’t believe in reputation systems. Though Game-Theory-wise participants in repeating games behave much nicer than participants in a single round game, I believe the decentralized and anonimized nature of cryptocurrencies prevents effectively building reputation systems without over-centralization. I hope to publish an analysis of TruthCoin following up on this point.
• I also wouldn’t trust any smart contract which is based on centralized data feeds. There’s really no point in a purely decentralized design that relies on a centralized data feed.