[Music]
hi everyone uh I'm ADI and today I'll
share with you my thoughts on chain
obstructions and the associated
risks so uh quick refresher what is
chain obstruction um and its main goal
uh so the idea here is to provide a user
experience um that is all about enabling
users to use applications without having
to interact directly with Bridges or
chains so uh what can possibly go wrong
here uh this is a very simple example
where uh poor implementation of
obstruction uh led to a user losing uh
some font due to slippage what happened
here is that uh user tried to bridge
from digent chain back to base and
because the UI was using an external
Bridge instead of a canonical one uh it
first had to slap funds to eat and this
is where things went wrong so the user
incurred an 87%
slippage um and the thing is that this
wouldn't have happened if economical
Bridge was used or maybe if the user was
informed that an external bridge is used
or if they had the option to choose uh
so this example is trying to show the
pitfalls of accountable struct of chain
obstruction when implemented on the
wrong
level so how how can we do it
better um there is this example of an
intent based protocol and there are lots
of different designs but the idea here
is that part of the risks are moved away
from the user uh so here we have this
entity called solver uh that basically
once the user deposits funds the solver
almost immediately provides the funds to
them on the destination chain the idea
here is that the user still has to trust
the solver to not censor them and the
ASC smart contract on the source chain
uh but apart from this they don't have
to care about uh finality and settlement
because those are risks that the so is
taking instead of them
and uh there is this concept of chain
abstracted balances uh this is the third
example um the thing here is that if the
user only sees uh one total balance uh
that they have across all chains they
might um not realize uh that for example
most of their funds are on a highrisk
chain and this is because um the assets
that you have uh inherit all the risks
of their underlying assets which depend
on the bridges and the chains that were
used this an example with AP on AP chain
but there are lots of different examples
and here um the token that is on AP
chain uh is basically inheriting
security from the canonical Bridge as
well as layer
zero um so the point that I want to make
is that um first of all uh if there are
any risks uh that where the US
can
[Music]
um that can still affect the user and
they can potentially lose funds they
should be shown to the user they should
not be hidden and in the example with
the chain um abstracted balances uh I
believe that at this stage we are not
ready to hide the risks uh just because
the most of the chains are not secure
enough um so chain obstruction should
not be risk abstraction in a sense where
uh there are risks that um the user is
not protected from and they are not
aware of them and they might cause funds
to uh get stolen or
lost but chain obstruction uh should be
risk obstruction in the sense that uh we
should try to protect the users from
those risks and this can be by uh
limiting some uh actions on the front
end or by introducing some additional uh
entities who would bear the risks
instead of the users
and um as a last thing I want to say
that we at L2 beat um want to um I mean
we believe in transparency and we also
like red warnings so um we introduced
these two called Insight where you can
check all the risks of your portfolio uh
by inputting your address uh so in this
example you would see all the underlying
tokens of uh a on AP chain and all the
risks that come from the canonical
Bridge or lezero or the token itself uh
and this is mostly targeted towards
regular users who want to know how risky
the assets they hold are but if you are
um developer um and uh you want to make
the best decisions on behalf of your
users you can also find this useful so
uh make sure to check it out once it's
life
thank
you thanks Rina all right we have time
for some questions who wants to ask one
raise your
hand don't be
shy you can do
it if not I'll ask a question and I know
your your questions are better yes
amazing hello
you and
catch um I want to ask like for a simple
Finance product um like a very very
simple one without all the sophisticated
stuff what would you recommend to devs
um obviously when you're on boarding
completely new be users you you don't
want to expose everything what would you
recommend devs
to yeah so um I think that uh when if
the developers want in some way to
onboard users without introducing them
to the complexity of the chains and the
bridges so using some kind of chain
obstruction um in case they don't want
to surface all the risks because it can
be overwhelming they should make sure
that they make the best choice for their
users so it can be something like
limiting the chains they support based
on the risks that uh they might
introduce or limiting the assets or uh
maybe doing some kind of summary of the
risk like high uh medium low and then
profiling their users uh to show the RIS
depending on um yeah their user
profile thank you cool we have time for
another
[Music]
question anyone yes
here another question is that for the I
think the chain abstraction definitely
great user experience and also you
mention the risk mitigations as well but
in general Beyond like the Insight what
are there some of the kind of mechanisms
which should you guys put in place to
increase the user like you know trust
the confidence on of the reliability of
the abstraction on
that uh so the question is what
procedures should be followed uh uh
primar what other mechanism you put in
place to increase the credibility and
I'll increase the trust from the user
for the account abstraction
um all right so uh I think that when
implementing chain obstruction and um I
guess we can use this example with the
uh intent based protocols uh in this
case for example if uh the user has to
put some Trust on this new entity go
over uh we should uh make sure that it's
reliable so um maybe we can do something
like decentralized solare networks so um
for every trust assumption that the user
should make we should make sure that
this entity uh is to be trusted and it
is decentralized
enough cool and there's time for one
more
question let's see if anyone has
it I think someone has a question yes
yes
yes no that's okay uh