Staking as a fundamental building block for insurance

Let’s have a look at fire insurance. We’ll make some assumptions to keep the numbers simple, in reality the numbers are different, but you’ll get the idea. If you own a house worth $100,000, there is an assumed risk of 1% per year that the house will burn down (that’s once in a century). Without insurance, if you want to make sure you always have a home, you need to have an additional $100,000 on top of the $100,000 you invested in the home to replace it in the event of a fire. This additional $100,000 may be challenging to come by, and it is very inefficient to have $100,000 in a bank account for an event that occurs on average only once in a century.

If 1,000 homeowners pool their risks, there are 10 homes worth $1 million that will burn down each year based on an anticipated fire risk of 1%. So, each homeowner only has to pay $1,000 as a premium into a risk pool to cover that ‘expected loss’ (the $1 million divided by the 1,000 homeowners).

This works well as long as there are no conflagrations. In the worst-case scenario, if more than 10 homes burn down in a catastrophic event, the pool will not be able to cover that loss. Examples of such devastating events include wildfires, hurricanes, and other natural events, as well as pandemics, terrorist attacks, and other man-made events, also called ‘black swan events.’

So what to do? The answer is to ask investors to add risk capital to the risk pool.

Suppose the probability of a conflagration burning down 100 homes is 0.1% per year (once every 1,000 years on average). The damage is $10 million. These high but implausible risks are also called ‘long-tail risks’ because they are represented by the ‘long tail’ of the risk distribution curve:

*Visualization of the '`long tail.’

In addition to the $1 million paid by premiums, you need another $9 million from investors. For example, they will charge a compound interest risk of, say, 5%, which equates to $450,000, so each homeowner would incur another $450. But with a total premium of $1,450, they are now insured not only against the typical risk of 10 burned homes per year but also against the risk of a once-in-a-millennium conflagration and everything in between.

Investors must commit their capital for the entire lifetime of the insurance policy because otherwise, they could move out of their capital as soon as there are signs that a ‘Black Swan event’ is becoming more likely. And, of course, the groups of insureds and investors could also overlap.

Traditional insurance features very high administrative fees on top of this lifelong $1,450 premium, which can be done away with by using decentralized blockchain-based insurance.

A risk pool is a smart contract that collects funds that are used to compensate for insurance claims.

In its simplest form, a risk pool could be a multi-signature that would be funded by some interested parties, be it investors or product owners. The risk pool is registered in the GIF (Generic Insurance Framework), approved by the Instance Operator and connected to one or more products that are registered in the same GIF instance.

The party which organizes the risk pool is called a ‘risk pool keeper.’ Premiums from purchase of policies are paid into the risk pool, and claims are covered from the funds of the risk pool. In this most simple form, investors have little control over their investments, therefore the risk pool and its keeper need to be trusted by the investors. To address this need, we have developed a concept that enables us to launch trust-free risk pools which can be operated in a decentralized way.

For a trustless risk pool to function, methods must be implemented that technically and transparently guarantee that the interests of both insured and investors are met.

For the insured, this means that we can prove that the risk pool will always be able to fulfill claims.

For investors, this means that they will receive a fair share of the profits made, and that they can decide for which risks they will engage with their funds.

For both, this also means that the risk pool needs to be economically attractive for investors, without whom there may not be enough capital to enable the purchase of policies.

It is clear that it is challenging to design smart contracts which fulfill all of these guarantees, given that the amount of calculation involved on-chain needs to be limited.

While we expect that sooner or later, e.g. with the further rapid development of zero-knowledge-proofs, it will be possible to perform arbitrary complex, untrusted computations reliably off-chain and verify the results on-chain. This brings the need to devise a system which is somehow simplified, can be run fully on-chain and still meets the mentioned requirements.

We achieve this goal by using so-called ‘epochs.’ An epoch is a period of time that is typically a small fraction of the average period of a policy. For example, flight delay policies typically have a period of a few days to a few weeks as the maximum. A good choice for the duration of an epoch would then be a week. For crop insurance, the period of the policy is typically some months, so a good choice for the duration of an epoch would be one month.

For each epoch, all policies which are sold in this epoch are handled equally. This step massively reduces complexity.

Each risk pool needs a function that enables the risk pool to receive premium payments. The function may only be called by a registered and approved product contract in a GIF instance. Premium payments can be made in the form of a native token of a blockchain (e.g. xDai on the Gnosis Chain, or ETH on Ethereum Mainnet), or in the form of a stablecoin (e.g. USDC).

Each risk pool needs a function that will payout a claim in case of a loss. The amount of the payout and the decision if a certain loss will trigger a payout is controlled by the product contract. Therefore, this function may only be called by a registered and approved product contract in a GIF instance. The product contract also needs to specify in which token or currency the payout is made.

Each risk pool needs a function to receive investments. Investments can be made in any currency or token which is specified by the risk pool keeper. Investments need to be registered in the risk pool, so that an investor can always check the status of his investment and the share of profit he makes during his investment.

The risk pool keeper may provide additional requirements from an investor, e.g. KYC. The GIF framework supports the implementation of such requirements, but they are not enforced by the framework — it’s the responsibility of the risk pool keeper to enforce them.

No investor wants to invest for an unbounded time, so we need to provide a mechanism that allows withdrawal of investments.

This mechanism is designed in a way that ensures that there are always sufficient funds available to cover losses.

The bookkeeping system which tracks investment deposits and withdrawals is the most complex part of the system.

Part of the premiums paid are used as revenue for investors. Investors lock their capital for a certain period of time and risk losing all or part of their investment. Therefore, a revenue is needed to make an investment attractive.

Profit and revenue need to be distributed among investors in a transparent and fair way, according to the time the funds have been locked, and the risk taken.

The distribution mechanism is another complex process and will be described in the upcoming part two of this tutorial in more detail.

Risk pools vary in size, depending on the demand of the underlying product. We will provide mechanisms that will enable autonomous control of risk pool parameters so the risk pool will reflect increasing demand of the product by increasing the attractiveness for investors, and vice versa.

Therefore, a risk pool can be connected to a product with a feedback loop. Should the demand for a product increase, the risk pool could increase investors’ revenue to make the risk pool more attractive for further investments.

On the other hand, given that there is a lot of capital available, the risk pool could trigger a price adjustment to make the product more attractive on the market.