 Hello, okay microphone is on hello. My name is Christoph Musenbrock. I'm from either risk and I want to talk to you on standardized protocols for decentralized insurance as you know either risk is building decentralized insurance and decentralized insurance Of course has many participants which have 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 be 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 Sallenberger who managed to land Boeing on the Hudson River and why was this possible? They had birds in their engine and all engine at once stopped and this wasn't pleading in the 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 the cockpit communication So every single step in the communication is according to a predefined pattern Which has 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 ensure communication and of course in insurance, which is very critical business We need protocols to ensure the communication between participants Now what are our requirements for good protocols? We want to build a standard for protocols for interaction between Participants in an insurance network these participants can be customers. It can be service providers like oracles 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 it will fill 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 is not behaving exactly according to the protocol. This should not Stop the whole process. So a 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 only sense if everybody agrees on it and Yeah, we have a perfect example the REC 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 a 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 to get it to initiate it or to get information, but the transfer function is Most important. So you have a very minimal set. It's robust because you have very few input parameters and so it is mainly mainly impossible to to go against the rules of the protocol and It's secure because it is 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 REC 20 token You can now build for example 0x exchange or on top of this again other exchange protocols So the REC 20 token is I think in the middle below there is solidity. There are Standards like self-message. We will see this 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 Very low technical layer, which is dark gray. It's a cerium client implementation with parity and guess 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 EVM we have higher order languages solidity by Pereska, 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 which can choose Viper. It's Mostly used solidity, but of course you can do other languages as well So this is not hardly connected But only a weak connection and on top of the higher order languages and we have the coding practices security standards Libraries and of course we have the first business standards like the REC20 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 BPM and 2 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 that 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 which we know and then we have the verticals insurance banking and others and Now these can already interact by using these Atomic 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 core 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 invite all of you to work on this to make your own extensions and to To make this a very generally accepted standard. So this is our strategy We want to open source the whole protocol It should not be a proprietary protocol But it should be open-sourced and it should evolve as a work of many in the community The first example is our flight delay. Maybe a third 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 Pro-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 with the upper layers the next layer is still also a 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 and you can do this without exchanging all the Data so if 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 processing contracts Then we have of course other partners on the which we interact with for example in our we have Oracleize 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 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 chatbot is a work of a separate team which has nothing to do with either is other than we are friends But they do it on their own and they can as how 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 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, so 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 this against the immutability paradigm of blockchain, but the immutability 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 can have bugs can have 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 a 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 we we send a query to the Oracle and the Oracle will then request the data source and Put and give us back the result via a call back 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 if they pay for the query and we get a call back and it's working perfectly Thomas very you he's the guy and We are very Satisfied with the service but still we 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 a mechanism, which is basically a staking mechanism We will incentivize Oracleize 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 He takes the staked tokens to Pay for the fallback solution and this is a very generic mechanism. You can exchange Oracleize 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 this would be in a company context in the company context We have also in sent incentives Yeah, if somebody doesn't behave well you can fire him or you can reduce his wages in a decentralized context We need other incentives and such a mechanism is a very generic mechanism Which enables complex products on the blockchain with 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 mechanism for example instead of staking we can also Reward somebody to behave properly we can say if you deliver in time then 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 will introduce in the next slide So this is the basic rule, 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 or 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 a service for this the service producer Has to build up an infrastructure and for this he takes a bank credit or a loan 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 Leads to high capital in an infrastructure cost and for it is not censorship resistance. Yeah, people banks can Shut up the 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 a 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 close Society because the capital requirements are so high Small companies cannot afford the capital and so they are excluded from participating in this network by sharing the capital and the infrastructure be 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 excess to people who have contributed to the capital and then we are Coming to a generator usage token model, which is also emerging I we are not just ready with this but we are thinking about such a model Gnosis has it another very well-known project, which I don't want to speak out as it and So I think generally 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 the heart is outside this is a artificial heart and we are moving the heart inside so We hope that this is a 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 to participate in this network, and this is an emergent process. We can't We can control this completely, so we don't want to control it We 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 and Thank you