Betting on Blockchain Without an Oracle
The development of blockchain-based trading and betting platforms commonly requires the use of an oracle. The oracle is a trusted party inputting events of the “real” world into the blockchain. When the bet ends, the opposing parties will obtain their share of their deposited stake depending on the result which the oracle sent to the blockchain. One inherent problem of the oracle is trust. As it lies in the nature of the cryptography used in the blockchain, the oracle cannot prove to not be in the opposite position of the bet. Therefore, the general problem appears that the oracle could manipulate the result in its favour. Beside trust also technical issues can potentially corrupt the trade. This is in case the oracle denies the service or fails to supply the data. Then there is no other way than resetting the state and discard the trade.
Many bets are based on an underlying outcome which is of a continuous scale. The most interesting case for these kinds of bets might be bets which are based on stock market values. In the financial industry these kinds of bets are known as derivatives. To implement such kind of derivative on a blockchain, the actual price of the underlying has to be fed into the ledger. An authorised entity, acting as an oracle could obviously do this — with the disadvantages discussed above. Another way would be that both parties agreed on the true price. But how can one incentivise the losing party to agree on a price which would reduce their payout?
Now, bi-directional payment channels come into play which became of great interest recently due to the lightning network. The two opposed parties could lock their stake in a bi-directional payment channel and both sign a transaction to potentially withdraw their funds from the channel again. They could then exchange subsequent transactions to update the channel’s balance allowing to transfer money without transmitting the transactions to the blockchain. Only the last transaction signed by both parties is valid which can be broadcast to resolve the payment channel. This allows both parties to send transactions on a very high frequency as long as no one opts out.
This concept can be used for bets on stock market values allowing a new kind of price settlement. Stock market values generally show some volatility and follow theoretically a random walk if events like sudden crises are neglected. On a short timescale of minutes and seconds the value changes are typically way less than 1%. This is usually much less than what a trader is looking for. Therefore, a trader might accept an intermediate small decline of their potential payout while being aware that in the next second an advantageous change could increase it again.
One could think of additional incentives to avoid that a trader opts out. For example, an asymmetric payout pattern could be used (see figure below). The idea is to incentivise the winning party to broadcast the most recent transaction. However, the trader who publishes a transaction, has to pay penalty to the other trader. Consequently, if the penalty is larger than the volatility of the underlying, the losing trader would get a higher payout from the new transaction published by the winner than publishing the old transaction himself. If both traders agree to terminate the trade in the end, both can agree on the actual payout without penalty.
This kind of high frequency payment exchange could also work for other kinds of bets which are based on underlyings with continuous data. If the underlying was too volatile, the participants could agree to average the underlying value over a certain period. The major issue of the concept could be an asymmetry of information where one trader has access to the new values a certain time ahead. However, if the changes of the underlying’s value are small on this timescale this would probably only have minor impact.
