[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]