Making P2P Great Again, Episode IV: P2P Insurance
Digital currencies were invented to make the world better, but so far they have very little use in the real world. With prediction markets introduced in Episode III this is going to change.
There is one real-world need that applies to almost everyone and is closely related to prediction markets — insurance.
Prediction markets are about getting paid in case one of the two possible outcomes becomes real, the outcomes being uncertain at the time the prediction was made. Insurance is essentially the same, with the added perception of the outcome as negative. Which means that insurance is more than just a game of betting, it is also about buying peace of mind: if the negative event occurs, the received payment will be perceived as a compensation, not as a prize for correctly predicting the future.
If the other party of the bet is not also buying peace of mind, i.e. they are just making a calculated bet, there is asymmetry in relations of the two parties. The one who is buying peace of mind, is also extracting non-monetary value from the deal, hence he will be willing to pay more than the probability of the negative event would suggest. That’s one of the reasons why people buy insurance, that’s why insurance companies make money.
This is not the only reason why one would buy protection from a negative event and pay more than its probability suggests. The protection buyer can also face non-linear monetary loss in case of the negative event, e.g. a farmer may not be able to pay back his debt and face bankruptcy if a drought destroys his harvest.
The above means that by having prediction markets in Byteball, we also have insurance — a product that satisfies a real-world need, and a trillion dollar industry.
One such product is already working and ready to use.
Flight delays insurance
Delayed flights may disrupt your plans: from being late for a meeting to missing a connecting flight, and they are always a loss of time. You can’t stop them but it would be nice to get paid when a delay happens.
A successful experiment with flight delays insurance was already run on Ethereum in September 2016 and has proven that the concept works.
We have an oracle that monitors flight delays. You find a peer who is willing to bet that the flight would arrive on time, and create a contract with this peer. For example, you (the insured) pay to the contract 0.1 GB — it is the insurance premium, and the peer (the insurer) pays 0.9 GB. The money is locked in the contract until the flight completes.
If the flight arrives e.g. more than 30 minutes late (whatever delay is specified in your contract), you would be able to spend all the money locked in the contract, that is 1 GB. If the delay is less than 30 minutes, the peer can take all the money.
This is how you would design a contract for a 15 minutes delay:
This contract allows you to take its entire balance if Turkish Airlines flight TK414 on April 23, 2017 arrives more than 15 minutes late. The event should be reported by an oracle whose address is GFK3RDAPQLLNCMQEVGGD2KCPZTLSG3HN (this oracle is also a witness).
To get this event posted by the oracle to the Byteball database, you need to open a chat with the oracle (its pairing code is AuP4ngdv0S/rok+IaW1q2D6ye72eXLl3h+CqXNXzkBXn@byteball.org/bb#0000) and tell it your flight number and date:
The oracle (which is open source) will fetch data from FlightStats — a well-known source of air travel data — and post the delay into Byteball database as a data feed. As soon as the oracle’s data posting gets confirmed, you can unlock the contract.
If your flight was canceled, diverted, or redirected, this counts as large delay and would trigger the contract in your favor.
In your contract, you and your peer specify a period when you can request data from the oracle and unlock the contract if the flight was delayed. If you don’t do that, the insurer claims the money after this period expires. The period must end before one week after the flight completes, this is the maximum duration when FlightStats provides data about the flight.
Any regular flight that is covered by FlightStats can be used in the contract. Check FlightStats before signing a contract to make sure the oracle will be able to supply the necessary data (its coverage is quite good). Also check the past statistics about your flight and airline to correctly predict the probability of delay and estimate the insurance premium you are willing to pay or ask. Eventually, all this knowledge should be priced-in in the market price of insurance policies for similar flights.
Note that our oracle calculates delay by comparing planned gate arrival time (which is printed on your ticket) with actual gate arrival time, while FlightStats website sometimes reports runway arrival time, which is a few minutes earlier than gateway time. In most cases, they still have gateway arrival in the API which the oracle uses.
Like all other Byteball smart contracts, this contract is peer-to-peer and you can make it with any other user whom you don’t need to trust, because execution of the smart contract is guaranteed by the math underlying the Byteball platform. You also don’t need to trust the developer of the smart contract because the contract is a what-you-see-is-what-you-get, and either you create the contract yourself or the peer creates it and you can see clearly what the contract means.
As was mentioned above, the insured will be likely to pay more than what the actual probability of the flight delay suggests. This means that by being on the other side of the deal, i.e. by offering insurance to peers you are likely to make profit (on average) on your Bytes holdings.
The network effects
This is the first example of P2P insurance. To be accurate, this is parametric insurance, that is insurance based on occurrence of a widely known event, which makes oracle’s activity easily auditable.
The choice of risks that one is able to insure can be expanded easily and quickly by just adding oracles that report various other insurable events such as weather, investment ratings, news, etc.
Byteball is a network, and a network is strong thanks to multiple links between its different parts that keep the network together. With wide diversity of the personal needs of users on the network, a wide selection of risks that can be insured (the number of daily flights alone is over 100,000), and a choice of other users who can sell the insurance for profit, the network effects are going to be huge, and that’s what makes horizontal peer-to-peer links so great.