# A Standardized Business Model for Decentralized Insurance

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2018-10-09
- Duration: 20:53
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-86V_3sRnpWY
- YouTube: https://www.youtube.com/watch?v=86V_3sRnpWY

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/3/a-standardized-business-model-for-decentralized-insurance

We at Etherisc are building the first decentralized insurance on the blockchain. Decentralized means that we are not building a company only, but a standardized protocol and a platform on which many participants can build insurance products and trade risks.

Speaker(s): Christoph Mussenbrock
Skill level: Intermediate
Track: Economics


Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 3 was held in Cancún, Mexico on Nov 1 - 4, 2017
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] yes hello can you hear me hello okay microphone is on hello my name is Christophe muizenberg I'm from either risk and I want to talk to you on standardized protocols for the centralized insurance as you know is a risk is building decentralized insurance and decentralized insurance of course has many participants which has to interact with each other and this has to be organized in some way and that's where we use protocols for why protocol a protocol is basically standard which enables people to communicate you see Angela Merkel and the Queen and they are coming from very different cultural backgrounds and so it's not very easy to communicate but there is a protocol and this helps them to find the right way and another thing is protocols and able communication the other thing is also we have protocols which are very important for security look at this example you know all these famous flight from captain Sullenberger who managed to land Boeing and why was this possible they had birds in their engine and all engine at once stopped and this wasn't clear in an emergency situation and there were hundreds of people on this plane and such a situation creates much pressure and the only way to manage such a situation is that they use protocols in their cockpit communication so every single step in the communication is according to a predefined pattern which had been trained times and times and times again and so it went basically automatically and this was the reason why he could manage such an emergency situation so protocols and sure communication and of course in insurance which is very critical business we need protocols to ensure the communication between participants now what our requirements are good protocols we want to build a standard for protocols for interaction between participants and an insurance Network these participants can be customers this can be service providers like Oracle's data providers at actuaries this can be Claims Manager sales people so many people act together and to make the communication fluent a good protocol should be fulfill some core aspects and I have written down five of them a good protocol should be minimal it should not have any overhead at the same time which is nearly contradictory it should be complete so it should cover mostly the main cases which can occur and it should not be left open any space for friction it should be robust so if there are any errors or some participant it's not behaving exactly according to the protocol this should not stop the whole process so the protocol should be robust it should be layered so it should be from a simple generic layer to more complicated and connected layers and it should be accepted protocol makes the only sense if everybody agrees on it and yeah we have a perfect example the RAC 20 token standard is such a protocol it is minimal because it only contains I think six functions and two events and that's all and you know you can build a whole economy on such a simple protocol it's complete because everything you need to manage your token is in it and basically it is only one function the transfer function which makes it running all the other functions are more to get it we need to initiate it or to get information but the transfer function is most important so you have a very minimal set its robust because you have very few input parameters and so it is mainly impossible to to go against the rules of the protocol and it's secure because it's not possible to manipulate the balance of a token if it's done correctly it's very secure it's layered also because on top of the RSC 20 token you can now build for example 0x exchange on top of this again other exchange protocols so the RSC 20 token is I think in the middle below there is solidity there are standouts like self as variable ceases in another example and it's accepted everybody uses this of course and we want to do the same for insurance insurance is a bit more complicated than a simple token but the idea is basically the same we have a very low technical layer which is Darkrai it's a Syrian client implementation with parity and gas or other clients then on top of this we have the EVM which is in between we have a formalized semantics of the EVM I think there was one talk about this which is great you can now formally prove properties of the EVM and then on top of the ABM we have higher order languages solidity by Pascal whatever and there is a small gap between this because the lower two layers are very closely connected and basically you can separate them but then the higher order languages are already choice you can choose solidity huge can choose by it's mostly used solidity but of course you can do other languages as well so this is not hardly connected but only the weak connection and on top of the higher or languages and we have a coding practices security standards libraries and of course we have the first business standards like re-see 20 token which I would count as a technical layer but also has some connection to the business layer and then again a gap and then the green layers are already the business layers in our architecture we have first layer which is still very generic and does not know business verticals it's a business process engine which follows maybe some standard ppm n2 is already very widely accepted standard it also has a clear semantics and so you can prove properties of such business processes in such an engine and then on top of the business process engine which is still generic then there come the first financial processes for example payments assets data identity kyc procedures and governance procedures which are needed by mainly all financial processes on between now and then we have the verticals insurance banking and others and nowadays these can already interact by using these atonic processes and standards because every insurance needs a bank account it has funds to manage it needs an asset management and of course kyc for example is very widely needed for everybody and one of the big advantages would be that you could use customer which is identify once in every other business because we just reuse his identification and his certification of his identity so we have these verticals now and then of course every company can build proprietary extensions on top of it for example risk models or these the car insurance products which are different from each company but they are still on a very generic framework and our goal is to develop this framework we have already an example for this and we want to generalize it we want to extend it and we want to divide all of you to work on this to make your own extensions and 2x2 makes this a very generally accepted standard so this is our strategy we want to open-source the whole protocol it should not be a propriety protocol but it should be open sourced and it should evolve as a work of many in a community the first example is our flight delay maybe you've heard about it we have the first license insurance on a blockchain which is working completely on a blockchain I must specify this because others have already made some project protocols and products for insurance on blockchain but they are not processing the whole thing on blockchain we do we have the complete process on blockchain and you can now see the layers you have a very low level level the controller registry which is still on a technical layer it is a contract where you can register other contracts and you can store the addresses and the interfaces of these contracts so by looking in the registry everybody can see how to interact we see upper layers so next layer is still also generic it is an Access Controller database and the ledger we separate these three components because it's good for example - it's good to have all the funds in one very small contract because it reduces the attack vector it's a good thing to have all data in one contract so every other contract is nearly stateless if you have the need to exchange one component on the upper level then you can do this without exchanging all the data so it for example you need a different product specification and you can exchange it on the upper level and still all your policies are in the database and you don't have to migrate all the policies to a new level of the processing contracts then we have of course other partners on the which we interact with for example in our we have or class here which connects us to data sources which we need to process our contracts and these can interact with all these contracts and so we have a very flexible model here interesting thing and again is that we only have one single point of contact to the outer world to the front ends which is a is the connection to our customers so also a very small attack vector the front ends are very exchangeable we have our own web front-end but already other people other teams have built applications which communicate with our insurance contract for example we have an integration in status it's not on the live net yet but we hope to do this soon and this status integration is basically an app in the status client where you can interact with our insurance solution and this this chat bot is a work of a separate team which has nothing to do with is there is another than we are friends but they do it on their own and they can so make their own sales infrastructure and on money by selling flight insurance the risk model is a very closed module and the other modules here the yellow ones are very generic so you can plug in other risk models other products and use the same generic framework and next step would be to isolate all these generic features and publish them as an open source protocol and invite others to extend this protocol work on it and so that it becomes better and better yeah if you can if you have this organization then you can of course exchange a single contract here without changing the database some of you will maybe argue that it's against the immutability paradigm of blockchain but the mutability is basically here in the database and so we think it's a good idea to make contracts updatable because as you all know contracts can have arrows kind of bugs kind of attack vectors and can have breaches and so the ability to exchange as part of the whole system on the fly is a very important feature and for the customer we have still the full transparency and full fairness because every customer can see if we exchange part of the contract it will be visible and if we are doing anything wrong then this will be very public and so we have a great economic incentive to play fair with our customers because everybody will see if we are doing something which is not so good for our customers now we want to put a view on the role of tokens in this protocol we have our core process and we have now many participants which take one role for example here our Oracle and the Oracle is providing a service it's we we send a query to the Oracle and the Oracle will then request the data source and put in give us back the result by a callback but of course this process is sometimes interrupted there are many reasons but at the moment we have no no means to incentivize the Oracle to deliver certain service level we pay for the query and we get a callback and it's working perfectly Thomas yeah you he's the guy and we are very satisfied with the service but still we could imagine a situation where this doesn't work and in case he does not deliver we have to fill the gap and now we have invented an mechanism which is basically a staking mechanism we will incentivize orbital eyes to stake some tokens in our contract and in case he delivers not in their time then he will lose his tokens and we use this as a way to pay for a fallback mechanism because then somebody else has to deliver the data and this costs a bit of money and it takes the staked tokens to pay for the fallback solution and this is a very generic mechanism you can exchange or Clyde's against any other participant in the network and by such a mechanism we enable many participants to work together in complex products to work together properly and to agree on service level agreements and to incentivize such service level agreements and this is a new way traditionally is this would be in a company context in a company context you have also incent incentives yeah if somebody doesn't behave well you can fire him or you can reduce his wages in a decentralized context you need other incentives and such a mechanism is a very generic mechanism which enables complex products on the blockchain there's many partisans to be delivered on a very good service level and I think this is a basic feature of every business network which is working decentralized on a blockchain we have other mechanisms for example instead of staking we can also reward somebody to behave properly we can say if you deliver in times and you get an additional reward you can of course use our tokens for payments for staking collaterals for vesting and I will have another point which I really introduced in the next slide so this is a basic role but now you can ask after the economic model behind this the economic model is also quite easy in in a traditional context you have service consumers this can be the end users all this can also be companies and you have service producers or service providers for example think of insurance company which is using an Oracle the insurance company pays a fee for the Oracle or for the data source and gets the service for this the service producer has to build up an infrastructure and for this it takes a bank credit or alone and so the capital provider gives a capital the service producer pays an interest rate and this is all very expensive as you know and for and above all this is very limited this structure here leads to high capital in infrastructure cost and Forex it is not censorship resistance yeah people banks can shut up loans and then disrupt the business and this happens so this structure leads to centralization effects and monopoles and it leads to exclusion and exploitation so what can we do we can put the capital in the middle we share the capital and the infrastructure and every service provider becomes the service consumer and so both roles are combined and now these are interacting and they share this capital and the infrastructure and this is of course a model which is very apt for insurance because insurance works on lots of capital and this is why insurance is such a closed society because the capital requirements are so high small companies cannot afford the capital and so they are excluded from participating in this network we're sharing the capital and the infrastructure we enable many participants to be part of such an insurance network and then this leads to another question how can we how can we restrict the access to people who have contributed to the capital and then we are coming to generate a user token model which is also emerging I we are not just writing business but we are thinking about such a model can also says it another very well-known project which I don't want to speak out and so I think general usage tokens are very apt for such a model with a shared capital and shared infrastructure and we will elaborate on this and hope we will soon be able to present more details on this basically if the capital is outside of such a network sahabas outside is a artificial heart and we are moving the heart inside so we hope that this is more convenient and more decentralized solution and that we are working on and of course this takes a big community community building is important we have lots of challenges and so we hope that we will see adoption of our network we have this is our core business to talk to people to in to invite people to participate in this network and this is an emergent process we can't became control this completely so we don't want to control it you want that this is an emergent process and this is a work of many and so I want to close with this picture many people building on one house it's a complicated process it's not easy but as you know it can happen and we are happy to be part of this thank you very much for your attention end [Applause] [Music]