[trustless://eil] Ivo Georgiev - Integrating EIL into Ambire

Transcript

Uh so on that note, the next thing that we are going to be doing is integrating Ethereum interoperability layer into Amire and that is going to be with Ivo Georgiev. All right, you can come right up. Thank you. [applause] Hey everyone, you guys can hear me. So that's a good sign.

So just waiting for the slides. Um first of all I'm Evo. I'm uh a co-founder of Umpire and CEO. And uh first of all let's start with what does mean? Uh so what we want to do is we want to make selfy more accessible to everyone. Uh and in order to do this uh we essentially need to make it easier, more secure and also more private. So uh what is EIL's mission? So essentially EIL's mission is to make Ethereum feel like one chain uh which is something that tons of projects do um and tons of projects promise. Uh but the

big difference with EIL is that the whole goal is to make to do this without compromising on the crop's values. So essentially without compromising censorship resistance, uh open source privacy and security which is also something that umpire is really aligned with. So uh problem statement. So why do we need to solve this problem in the first place? Why do we need to make Ethereum feel like one chain? Uh we all know about this. We've all we we've all seen this. uh having like five USDC's and having like three or four ethers and this problem is even made worse when you consider that most layer 2s require uh some kind of a native token and in order to have gas in order to use this layer 2

uh you need to have ethers on multiple networks uh so that's really fragmented uh and yeah that's also another problem that buyer solves but EIL solves as well u so first of all the thing is why don't we simply consolidate this we have been asked about this for maybe two or three years ever since pretty much umpire was launched. Why don't we just sum all of the USDCs, sum all of the ethers and show them uh show them in one entry. So the issue with this is that this is a leaky abstraction and what is a leaky obstruction? A leaky obstruction is something that you try you try to hide some complexity but then uh it kind of wields its ugly head uh a little bit later in the user flow. So one example

of this is you go to a DAP that only supports a subset of those networks and you only see a subset of your balance or you even see a balance that you don't even recognize. So you could have a total of 100 USDC uh but in a certain D you're going to see 10 which is scary. And then another example of a leaky abstraction here is imagine that the user flow is very simple uh for 10 USDC but when you add only one the user flow becomes completely different because you have 10 on the chain that you need to want to do something but um when you want 11 on that chain it has to pull this one from a different chain. So one USDC could be a difference could could be the difference between only one

transaction signature or having not only to sign multiple transactions but to wait for a bridge uh which is in my opinion pretty horrifying. So uh how does the Ethereum interoperability layer helps help us uh solve this? So the essentially the core uh thing that we use from the Ethereum interoperability layer at the moment uh is the multi-chain execution. So essentially the ability to sign operations on multiple networks um in one in only one signature. So um I'm sure that all of you will be asking this question not only once but many times today. Uh how is this different? How is this different from the open intent framework or how is this different from the intent model in

general? And um the the way to explain this is like is not short but uh basically they cover completely different bases. They're completely different concepts. uh and uh transactions describe very exactly what you need to do and intents describe very abstractly what the user wants to do. Uh but they're not competing with each other in a sense that uh you need both of those concepts. Uh so um in a practical example um in a world like umpire the user would need to um want let's say you want to use a balance from two different chains and you want to go on a third chain and buy some NFT. In that example, you can still use intents like the wallet can broadcast to an

intent network. It can say please give me the most optimal solution and then solvers would compete for the optimal solution and they would relay this solution back to the wallet. But then the execution is something that the Ethereum interoperability layer actually helps us with. So you can think of it as an execution engine that can be used either with intents or without intents. So in many ways it can replace intense for simple use cases because it also it also includes a primitive for moving uh assets across chains. So in some ways it can replace intense altogether but as I said they're generally completely different things uh and you can think of the Ethereum interoperability layer as an execution engine uh for those

intents. So another way to explain it in a classic intent system uh you will have an intense execution engine and you'll need to give approvals for this intent execution engine smart contract for it to work which is still a very big user hassle and with EIL you would be able to just one signature and um execute whatever you want to execute. So uh what is it useful for right now from unbias perspective? So from a wallet perspective, what is Ethereum interoperability layer useful for right now? So first of all, one of our main like holy grails of chain obstruction, right, which is balance consolidation.

Um making everything feel like one chain, consolidating balances and doing it without leaky obstructions. So doing it without introducing complexity later down the flow. Uh and then the second thing that um that is really cool for is uh fixing user experience for multi-step bridging. So what this is is right now we use uh third party providers like socket and lifi to do bridges. Uh later on we can replace that with the open intent framework or with some other more open decentralized solution. But my point here is is that those solutions they provide two modes of operation in that sense which is single step and multi-step. And in the singlestep flow uh the user only has to sign one

transaction. In the multi-step flow, the user has to sign one transaction, wait for the bridge, and then sign a second transaction or maybe even third. Uh so the problem with this is that it's incredibly incompatible with the modern user. The modern user doesn't have the attention span. And I don't blame people. Obviously, I also want everything to be done immediately. Uh and more importantly, when a user, we have conditioned users that when you've signed the transaction, that your work is done. From that point on, you're simply going to wait for something to to be accomplished, for something to happen. Uh so with the EIL we can ask the user only for one signature and authorize a chain of actions. So not only like multiple transactions that are going to happen that are going to get executed at once. No, we're executing a

chain of actions where the second action can get done after we wait for a specific bridge uh or something like that. Uh so this opens the door for uh essentially more solutions from socket, more solutions from LiFi and essentially better UX. So um what can it be useful for down the road? So the cool thing is from a DAP perspective uh Ethereum will also feel like one chain. of this helps dubs scale and as a dab developer one day you will not need to care that much about the underlying layer 2 that you're deploying on and everything feels like um essentially like the same thing and as I said it's a primitive for authorizing chained crosschain actions

so this is really powerful and with this classical bridges might even become unneeded uh because a lot of the functionality of the bridge is handling what happens after the funds uh go into the destin ation chain. So I want to show this in practice and uh I hope this works and we have a video here which uh I'm hoping that the team will play anyway. So I can tell you about what's going to happen in the video before we get it played. Um so essentially what's going on is um we have two videos and Um, I have a video of Stitch. Yeah. Yes,

please. Okay. So, since uh we're not getting this played, uh we can get offer to show you Stitch right now. Hopefully live. Amazing. Okay. So, I had two demos prepared. one with umpire rewards which is our own dub and then the second one was with stitch uh which was much more impressive. Um and yeah hopefully we can get that done. Uh can we please get offer connected?

So anyway, uh you already saw a demo of stitch recorded. So something that I also want to point out here is that clear signing is in the works uh because you only saw that we're signing hashes. So yeah, clear signing of the whole user operations multiple uh is in the works and it's going to be like super clear to the user what's going on which is also kind of a cool thing about the the interoperability layer. So we have stitch on the monitor but yeah we have stitch here as well. So um stitch can do many things but uh from the ambar perspective what I was going to show you uh is balance

consolidation. So essentially using USDC from a bunch of different chains and essentially in this case we um we go to limitless and we make some bet and yeah so the cool thing here is that there are going to be four user operations in total. So um the first three are going to consolidate balances from three different chains into one chain and then the fourth is going to buy that share on Limitless and all of them you're going to authorize with only one signature.

And again all of this is happening with gas obstruction. So you don't need to care about gas fees. You only pay gas once on this. And any moment now, hopefully the internet is good enough, we're going to get an umpire popup here. the risks of a live demo.

Okay. Anyway, everyone, are we going to try again? >> Okay. Get kicked off the stage. We're going to keep trying. In the meantime, do we want to take a question? Maybe. Yes. I'll repeat it. >> Forgive me if I asked this wrong, but how does the user get the best price or swap using EIL? Like how because if if it if it's the way it was described before, like an intent, you don't know how you're going to get there, but you

know what you want the end result to be. EIL is lower and it should just like you should pass the specific values like your a like a token or even a function or a protocol address or like so how does that work like how does >> so essentially essentially those are solutions to two different problems so we still need to solve the problem of how you're doing the swap this is out of the scope of the EIL the EIO is more of an execution engine which allows the empowers wallets um to let you their users have a good UX of doing multi-chain actions at once and authorizing multip multi-chain action at once but the problem of how the swap gets solved uh is still separate. So this is why I said that they're not conflicting with the open intent

framework even though in some small use cases the can replace uh the open intent framework but generally speaking those are two separate domain problem domain spaces. Yes, the the EAL is a transport layer and is the same as the transfers and all the protocols you've seen like swaps were uh using DEX DEX operations. That's what stitch does. It lets you do uh the swap on the source chain, destination chain, EIL does the transport. >> Okay. >> All right. Um we're out of time, but I'm checking if we can take one more question. Yes or no?

Okay. No, that's it. Thank you everyone. [applause] Thank you so much, Eva.