Assume 100,000 homeowners are coming together in a pool. Again, everybody pays a $100 share; this amount is now called the “premium”. They collect a total of $10,000,000 in premiums. But now there is a difference to Alice, who takes care only for herself: because of the law of large numbers^[4], with a very high probability there will only be about 100 fires, causing a damage of about $10,000,000! And because the sum of all premiums is also $10,000,000, the whole damage can be paid out of the collected premiums, there is no need for every house owner to take on a loan. (Because premiums are collected at the beginning of the year, and all the houses “expected” to burn don’t all burn at the beginning of the year, but more or less are equally distributed over the year(s), there is a so called “float^[5]” of liquidity which can also generate a significant revenue. For simplicity, we won’t focus on this effect in this paper.

So the costs for each single house owner are now reduced from $1,100 to $100!

This difference asks for an economical explanation. Let’s have a closer look. First, if all house owners would follow Alice’s example, they would need a huge loan, from which only a tiny part of 0.1% would be needed on average. It is clear that providing unused liquidity is costly.

Second, if everybody only cares for himself, only a tiny fraction of participants are struck by disaster, and have the burden of actually paying back their loan. The others can pay back without loss, as long as they don’t need protection. In an insurance collective, we have solidarity: with the premiums, everybody pays for the damages of the others.

To summarize, the risk pool offers three advantages for the participants:

Such a pool may be designed solely to benefit its’ participants, and to not make any “profit”. If the pool did generate profits, these profits could be distributed back to the participants, effectively reducing the premiums again to a level where no profits are generated. Such an insurance would have a loss ratio of 100%, because all premiums are used to pay the losses.

This is the very basic effect of risk transfer in insurance. Please note that the effect increases with the pool size.

But still, this is not the whole story.

In some years, there are more fires, in other years, less. To account for these variations in damages, the whole pool has to raise some money, e.g. $10M, to cover the unlikely event of a burst of many fires in one particular year. And let’s suppose that the interest rate for this capital is even particularly high, e.g 20%. We will have total costs for this capital of $2M. The interest rate for the capital is a function of the risk and the riskless interest rate on the capital market; in an efficient market, the interest rate will compensate for the higher risk in comparison with a risk-free investment and will also contain a fair profit. So basically, this is where profits are generated for providing capital in an insurance structure.

The overall costs of $2M are distributed among all house owners, yielding an additional cost of $20 per house owner per year, which is added to the premium.

So after this, there is also a protection against “tail risks” or “black swan events”, at a cost of $20 per house owner. Again, the risk diversification effect increases with the pool size.

Overall, participants now pay $120 per year for their house insurance. The loss ratio is now reduced to 83% because of the capital costs of protecting the tail risks.^[6]

To organize 100,000 people in a pool, a professional structure is needed. Otherwise, every single participant would have to coordinate, which would simply be impossible. The operation of this professional structure adds transaction costs to the premium. This is the reason why insurance companies have come into existence:

The effect is considerable and enables the modern form of insurance with huge customer bases and a capitalization which can cover even global catastrophic events like hurricanes and earthquakes. However, the remaining transaction costs are still considerable: a recent study by KPMG shows the impact on the loss ratio, which is about 66% in the average.^[8]

Together with the reduction of transaction costs comes an asymmetry of information, which leads to a further increase of costs and to incredible profits for the big insurance companies.

It creates an “unfair competitive advantage” for existing companies: companies with big data vaults can offer better products, and thus further optimize their database.

One of the core goals of a decentralized insurance platform is the disruption of this circle, giving back to customers the ownership of their data.

The three elements described above; risk pooling, risk transfer, and efficient administration are necessary. You can’t have insurance without each of them.
For the purposes of this paper, I will call them:

As we have seen, a community may not wish to generate profit from the first element. The second element yields a risk fee for binding capital which depends on the structure of the particular risk: It is typically lower if the risks are granular and uncorrelated; it is typically higher if the risks are clustered or correlated. The third one depends on the complexity of the process. A simple and highly standardized insurance “product” has a smaller transaction complexity than a more complicated, non-standardized product. This will be reflected in lower transaction costs.

The three elements are completely independent of the underlying technology, economic environment or currencies. They are the atomic building blocks of every risk-sharing system.^[9]

As an additional aspect we have seen the information asymmetry which is inherent in the traditional insurance systems, and which is undesirable.

The distribution of expected value (element 1) and capital costs for tail risks among participants (element 2) is inevitable and not specific for a blockchain solution. Therefore, let’s focus on the third element.

Transaction costs also appear in another context: regulations, which are deemed necessary to protect customers in a context with built-in conflicts of interest. Regulations form a very effective “competitor” barrier to entry. While insurance companies often complain about the burdens of regulations, they actually don’t have much interest in reducing these burdens, as they discourage new competitors from entering the market.

As a multi-trillion dollar industry dominated by huge corporations, insurance is often confronted with obstacles such as strict regulations, and misalignments of company and consumer incentives, which led to the insurance world often being inefficient and expensive. The ultimate goal is to avoid cases like customers having to fight for reimbursement from companies whose profits often depend on avoiding paying out in a targeted manner.

Etherisc is building a platform for decentralized insurance applications. The platform can be used by corporates, large and small, not-for-profit groups and insurtech startups to provide better products and services. We aim to use blockchain technology to make insurance faster, cheaper and more transparent and democratize access to investing in insurance products.

We encourage new groups building their own bespoke insurance risk pools and services on the platform. Etherisc framework enables fully-compliant and licensed insurance products for the emerging blockchain economy. To offer an alternative to traditional monolithic insurance systems, we can identify some requirements and consequences for implementing a decentralized insurance protocol.

As an open standard, the protocol is a common good, it can be used and implemented by whoever likes it. We will take care that the entry barriers are as low as possible. However, for some portions of the protocol, a certification will be necessary, to reflect regulatory obligations and restrictions. We have founded a swiss based foundation as a legal body, which formally holds the IP rights of the protocol and ensures that the protocol can be used freely. We established a continuous, community-driven protocol improvement process similar to the EIP process for the Ethereum Platform.

The Etherisc Governance Model (EGM), its abstract and core values as well as other subtopics will be further elaborated in Chapter No.5.

The success of the platform will depend on a vivid community of users and companies. The token model reflects and supports this community. This community plays a central role in the realignment of incentives. Via tokens, customers can “own” their insurance. The community model facilitates the development of future mutuals and P2P-Insurance models.

However, experience shows that there are some success criteria for communities. Famous open source pioneer Pieter Hintjens, http://hintjens.com/blog:10 has drafted some which we consider to be helpful for an in-depth discussion:

Insurance is a means of protection against financial loss. It is a form of risk management whose primary purpose is to protect against the risk of possible or uncertain loss. The loss associated with the risk may or may not be financial, but it must be reducible to financial terms.

An insurance company^[12] underwrites the risks of the insured. The insurance company can outsource all services, such as sales or data management, to other service providers. The only exception is the actual assumption of risk. This risk must always remain with the insurance company. Therefore, the company and their customers always need to have a proper accounting on which risks they cover and how it is collateralized.

An insurance policy is a contract provided to the insured by the insurance company that sets out the conditions and circumstances under which the insurance company will make payouts to cover losses incurred by the insured due to recognized claims. In TradFi, this is typically a legal contract. In our context, a policy is simply a dataset stored on blockchain and manipulated via defined rules by a smart contract.

Let’s look at the lifecycle of a typical insurance policy. Such a lifecycle usually consists of the following chronologically listed sub-steps.

Parametric insurance is an agreement between the insurance company and the insured that covers the occurrence of predefined events rather than manually reviewing and compensating for actual losses incurred.

Parametric insurance policies correspond to agreements between the insurance and the insured where the insurance approves payouts to the insured when predefined triggering events occur.

In parametric insurance, loss events (the risks) are defined as functions of underlying indices or parameters that meet the criteria defined by the insurance product. Example indices/parameters include rainfall amounts and wind speeds for insurance linked to weather conditions. In the case of flight delay insurance, the parameter/index can directly be derived from the difference between the actual arrival time and the scheduled arrival time of an insured flight.

Once such events occur, the insurance directly calculates and triggers a payout to the insured without an often costly claims acceptance process.

The big win of parametric insurance is its potential for efficiency and automation. Claims handling, one of the most complex and costly parts of the insurance business, can be reduced to a simple and fully automated process.

There are several benefits that blockchain technology can provide to the insurance domain. Some of these benefits are directly related to the foundations of blockchain technology.

Blockchain technology can provide a lot of value, especially for parametric insurance.

Risk transfer market
Raising capital to back the technical guarantees is done by investors. Investors will lock a certain amount of DIP tokens, also known as “staking.” The staked DIP tokens are a prerequisite to be then able to invest the actual risk capital in DIP or stablecoins.
The community of DIP token holders created the entire Etherisc ecosystem. Therefore, we will demand that parties who profit from the ecosystem own a share by holding and staking DIP tokens. This idea is borrowed from the space of cooperative enterprises. It reflects that the Etherisc ecosystem is a public good that needs to be protected from the “tragedy of the commons.”

Legal framework
Insurance companies are highly regulated worldwide for good reasons, to protect customers and investors. A great deal of legislation has been enacted for this purpose in most countries. Concerning jurisdiction, a general distinction can be made between the American, European and Anglo-Saxon regions.
But even within these regions, each country has different legal and monetary frameworks. Etherisc engages with local regulators to help create an efficient regulatory environment for blockchain based insurance. Etherisc supports interested parties and helps to guide the coordination process with the relevant agencies and ministries.
The financial and organizational hurdles to establishing a new insurance company are high. For countries like Germany, Etherisc offers a new legal model where the legal claim is exchanged for a technical guarantee using blockchain and smart contracts. Thus, the provider — in this case Etherisc — is no longer subject to an insurance company’s legal and financial requirements. Still, for each project, product and jurisdiction, the legal framework has to be considered and the product owner is responsible for the proper implementation. The Etherisc team has accumulated a lot of experience in this field and is happy to share these insights with platform users.

Technical framework
Developed and maintained by Etherisc, the Generic Insurance Framework (GIF) allows to model, deploy and operate insurance products based on blockchain in a decentralized and transparent way.
Using the GIF, interested parties can quickly implement and securely operate their insurance products.
With the GIF, it is technically possible to model insurance policies individually.

To operate insurance products, including selling policies, collecting premiums, calculating trigger events and handling payouts, a complete execution environment is needed in addition to the smart contract collections that define products and policies.

This execution environment — called a GIF instance — may be seen as a comprehensive platform or marketplace in which GIF-based insurance products are managed and operated. Our goal is for a GIF instance to be used by many different and independent providers offering various insurance products. The figure below provides an overview of the stakeholder roles involved with a GIF instance.

Each GIF instance manages different components. A component is a specific smart contract with a certain core functionality. The components can represent different core objects.
The core objects are:

All components and thus the objects they contain can assume identical states and have the same life cycle but can differ significantly in terms of lifespan.

Two roles can determine the life cycle of a component.

Component owner
A Component owner can be an oracle owner, a product owner, or a risk pool keeper, depending on which core object he manages.

Instance operator
The instance operator runs one or more GIF instances.

A component in the GIF is always in one of the following states:

The transition between these states and the roles which those can be triggered by are described in the above diagram. The lifecycle of a component starts with its development and deployment on the blockchain. The component owner can implement their specific requirements in the component’s smart contract or use the generic functionality of the GIF components. In the next step, the component is registered, approved and activated by the instance operator in the GIF instance. The instance operator can also decline a component. The component is then deleted.
In the event of approval, the instance operator continues to check the technical and procedural details. The instance operator can also outsource the verification to an independent audit.

If the component is active, it can be used until it is set to either suspended or paused. The difference between suspended and paused is that only the instance operator can suspend a component or resume it from suspended to active. The component owner can set a component to paused, the component owner and the instance operator can unpause the component. If the component is inactivated (pause, suspended) and not reactivated (resume, unpause), it is not deleted but archived.

For each type of component (products, oracles, risk pools) we provide sample implementations which can be used as a starting point.

Independent of the specific product, each policy processed on the GIF instance has a lifecycle. Typically, a policy undergoes several state changes during the lifecycle. While any product designer could implement his own lifecycle (in our terminology, the life cycle is called “PolicyFlow”), the GIF offers a default lifecycle which should be sufficient for most use cases. This generic life cycle is called “PolicyFlowDefault.”

The “PolicyFlowDefault” lifecycle offers the following functions:

The GIF instance is agnostic to the way payments are made. Pure crypto payments can be made directly to the product contract, while fiat payments need a fiat gateway and an external banking or credit card infrastructure. The core team can request information on how to implement fiat gateways.

The GIF monitor provides a structured overview of all generic building blocks available in the GIF framework for creating and operating an insurance product. You can view all events and business transactions of the complete instance.

The GIF monitor provides all this information transparently and in real-time online. The information is read from the blockchain and the GIF framework.

The URL https://gif-monitor.etherisc.com/ takes you to the ‘Home’ area of the GIF monitor. In the menu bar, you can choose from the following menu items.

In the ‘Home’ area you can click directly on the menu items in the menu bar and then select the corresponding menu item in the drop-down menu.

Core
The ‘Core’ area is by far the most extensive area. It displays the available GIF instances, the GIF core contracts per instance and the events of these core contracts. The core area shows the complete core contracts that each user can use.

Here you find the blockchains the instances use, such as xDai or Ethereum. By clicking on an instance, you will get detailed information like the instance ID, name, name of the blockchain, chain ID and status (active or not). Each instance is identified by its registry address. GIF is multi-chain capable and can run on all significant Ethereum-similar blockchains.

In this section you will find all 14 GIF core (smart) contracts. Each core contract provides essential functionality to a GIF Instance.

You can click on the contract name for all GIF core contracts to get to the contract details. Here you will see on which instance you are, the instance ID, the address on the blockchain, the name of the core contract, and the detailed contract functionality as described by its contract application binary (ABI) interface.

Here the contract events of the GIF core contracts are displayed.

Contract events are emitted by smart contracts during code execution and permanently stored on the chain. Events are primarily used to document significant changes in the data of the smart contracts, for example the change of status.

Oracles
The available oracles are displayed in the ‘Oracle’ area of the GIF monitor.

On this page, you will find all oracles available on the platform. Here you can view all input and callback formats as a product owner. In addition, the appropriate oracle can be requested from the Oracle owners.

By clicking on an oracle, the GIF monitor displays the details. Of course, individual oracles can also be implemented on request.

Products
In the ‘Products’ area, all products are listed that have been created in the framework. By clicking on a product, the details are displayed.

Policies
In the ‘policies’ area you can find information on every phase of the life cycle of a policy. Starting with information about the product, metadata, application, policy, claim and payout. Depending on the policy’s life cycle, more or fewer information blocks are displayed.

When you buy an insurance policy, you expect a payout in the event of a claim. To ensure that there is always enough liquidity to start or continue selling policies and to service all payouts, we plan to set up a system with two corresponding risk pools.

The two corresponding risk pools will collect premiums for all policies sold and additional liquidity provided by investors. Each well-designed risk pool is subject to an actuarial model for the insured risk and thus determines a certain probability of default for each policy.

We define staking in the decentralized insurance context as:

Net premiums (after deduction of costs) from the purchase of policies are paid into the risk pool, and claims are covered from the funds of the risk pool. An investor chooses an investment option based on risk tolerance and portfolio structure.

Alternatively, the investor selects his investment according to ethical aspects such as environmental friendliness, climate neutrality, or social commitment. If necessary, he accepts a lower profit to offer insurance to small farmers, for example. We will always encourage the implementation of green & fair products on the GIF!

For a trustless risk pool to function, methods must be implemented that technically and transparently guarantee that the interests of both the 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 they receive a fair share of the profits made and can decide for which risks they will engage with their funds. This results in the need for the system to run entirely on the blockchain. On blockchain, computation is expensive, so we need to keep these calculations efficient. To achieve this goal, we plan to implement "epochs" into our risk pools. The duration of an epoch will depend on the product. For each epoch, all policies sold will be treated the same. This step reduces the complexity massively.

The core economic process of insurance, the transfer of risk between insureds and investors, is implemented in the GIF framework through risk pools.

While the standard risk pool template includes all the core functions for processing premiums, claims, deposits, payouts, and returns, the template leaves maximum flexibility for risk pool keepers to design their pool’s economic model to appeal to insureds, product owners, and investors.

The primary risk pools (PRP) will receive the net premiums (i.e. gross premiums minus costs) paid by insurers in stablecoins (e.g. USDC, in this example, or xDai at Flight Delay). in exchange for assets staked by the investor The PRP will generate risk pool NFTs.

An investor will not transfer his DIP token directly into the PRP but into the SRP. The deposited DIP tokens are collected and transferred to the PRP at the end of an epoch, and the PRP generates a new risk pool NFT; the owner is the SRP. The investor receives the equivalent value of his deposited DIP tokens in risk pool tokens (RPT) minted by the SRP.

The global staking pool will span all primary risk pools of a GIF instance. Comparable to reinsurance, the pool steps in if, for example, black swan events lead to the insolvency of a primary risk pool, then the parachute pool steps in. Investors can also stake their tokens and stable coins in the global staking pool.

If the investor stakes assets in the primary risk pool, he receives a risk pool NFT as a receipt. While NFTs are tradeable in principle, we expect the risk pool NFTs to be illiquid. To facilitate trading of risks, we will introduce fungible risk pool tokens (RPT) via so-called “Secondary Risk Pools”. A secondary risk pool will acquire the risk pool NFTs of the primary risk pool and fractionalize it. Investors can invest in a secondary risk pool and will receive fungible (ERC-20) risk pool tokens in proportion to his share in the secondary risk pool. New risk pool tokens are minted when new capital is deposited into the pool. For each pool, specific RPT are minted.

The NFTs are linked to a specific PRP and cover risks of individual insurance policies. The NFTs remain in the SRP and the RPTs in the investors' wallets. When all policies linked to an NFT are expired and all associated claims have been paid out the investor can withdraw all assets associated with the NFT.

We want investors to deposit and terminate as quickly and efficiently as possible. But the protection of other investors and policyholders is also essential to us. So we have found a compromise that benefits all parties, the Epochs.Epochs massively reduce computational complexity, a limiting factor in smart contracts due to blocking gas limits. The epoch concept can execute every transaction with a fixed gas cap.

In the first release of our risk pool, we will offer single-sided staking only (the risk is taken by a stablecoin only). However, you need to stake a certain amount of DIP tokens in the Global Staking Pool, in relation to the capital invested. So only when you have staked the base amount in DIP tokens can you contribute risk capital in the form stablecoins. In the future, investors will be able to stake different assets - not only stablecoins - depending on the requirements of the risk pool keeper in the risk pools.

The standard offered by the generic insurance framework is simple. Premiums are added to the risk pool (after deducting costs) and increase the value of the risk pool tokens. Payouts are paid from the pool and decrease the value of the risk pool tokens.

In the standard implementation, profits initially remain in the pool. Profits are realized the moment capital can be withdrawn from the pool.

Investors receive their premiums in the epoch in which the contract is concluded. The premiums paid by policyholders are credited proportionately in the ratio of personal risk capital / total risk capital. Any refunds in the event of a claim are shared proportionally by all risk capital providers who have contributed to the premiums since the policy’s inception.

So if you have two investors, investor 1 has DIP 100,000 staked, investor 2 has DIP 50,000 staked. Insurance is taken out with a premium of USDC 30. Investor 1 receives the equivalent of 20 USDC through the price gain of his RPT, Investor 2 receives the equivalent of 10 USDC. The USDC remain in the PRP.

If a claim is then made at USDC 90 on that policy, the USDC 90 will be paid out of the PRP. Investor 1 loses the equivalent of 60 USDC, Investor 2 loses the equivalent of 30 USDC.