[trustless://interop.landscape] Workshop - Effortless DeFi: Extending the EIL SDK

Transcript

ution that can be involved at multi steps with actions. We're going to talk about actions in a minute. And um batch mean an executions that can end up or start with a voucher. Voucher is the element that in charge for uh transferring funds uh between different chains. Uh creating a voucher means uh depositing funds into a contract that later will be uh claimed by um the same uh signature on a different chain. Um and on on that case you actually get the the bridging transfers from one chain to another.

[clears throat] What else we have on the concept uh stage beside actions and batches? Um there is a multi-chain concept since we're dealing for the first time properly in code with uh multiple chain. Um the idea is to create in code entities that will be involved with one more than one uh chain. In that case a contract should be handle um multiple uh should be aware of different chains and to handle multiple um addresses in case this exact same contract is uh available on more than one chain. So let's go a bit about uh uh this stuff just like to get you what we have and um and about the plan for

today. So first the idea is to show how easy is to have um a new protocol involved um in in any system that based on EIL. In that case we're going to get some couple of elements in order to make it happen. First uh as I mentioned actions are basically the the building block of execution on EIL. Um the the SDK the the the EIL SDK already provided some of those uh a basic action to call contract um an action to um um to call ERC20 approval transfer native token transfer and so on. But this is like very few of what can be done. What we

did actually and um part of this demonstration but also um of building stitch that Eva going to show uh in in this uh in a couple of minutes is um we built a logic that involved it multiple chain and multiple uh um um protocols. So in that case the the architecture that we had is to have each execution or each step that we want to have that relates to a default protocol as an action and on that case once you have action for deposit withdrawal uh stake uh wrap unwrap and so on you can later make a logic that involve with them and make the the great experience that we

have in TIL that involve with multiple chains uh multistep but with a single signature And uh so we're going to see how I'm how I'm going to create an action. Okay. But for that uh this action by the way will be add liquidity to unis swap. Okay. Um an action that involve with uh multiple two actually uh different tokens and calling the unis swap router. Okay. Before that we're going to create the entity of unis swap router and anything that relates to that. Okay. And of course at the end we're going to see it running uh with an example of USDC um uh from arbitum and USDT from base um

navigated into uh Ethereum and and then executed as a add liquidity call to unis swap and in between we're going to get ERC20 approval for both that is required for the third action. Okay, down to code. So, we're gonna see. So, let's open and I'm going to show around what we have. >> Fine. So, maybe I'll put it a bit more larger. >> So, what we going to have? So, uh first this is what already implemented. You can see um uh the following protocols already supported. We have uh Mofo and

Limitless and Lido and Aenlayer and B5 and a so on and so forth. And we can see that each one of them if you check a for example it's involved with all the elements that I just mentioned we're going to create the same for um unis swap uh liquidity pool uh deposit. Um so let's start first. So as I said we're going to have an action but before the action we need to have a a contract factory is right now unrelated but I want to have a contract in that case I already predefined the addresses of the unis swap router okay per chain address per chain is actually an an

entity that already a type already provided by um the uh eilst DK. And once I defined each one of those, you can check for example that this one on Ethereum is already here. Okay. So, we have the contract address we mapped per chain. And then next, we're going to create uh the router API. uh already set it up. But as it as easy as it sounds, it's about going to the uh we can use it scan, go to the ABI, just copy it, put it over here,

and this is considered done. So we have the ABI set and we have the addresses as you saw already set. And now we're going to create um a multi-chain unis swap router. Okay. Luckily we have AI here involved. So once once I'm doing export >> export class you already recognize that uh this is what is required and you can see that we basically in inherit from multi-chain contract okay that is a a class involved with uh that actually represent a contract in EIL SDK what is

expecting as um as parameters for the constructor is the client because we want to execute through this contract. It also requires the AI as we already defined. Okay. And it also requires the addresses the addresses map that we saw in advance. A side comment, we don't necessarily need to have all chains supported. It's enough to have one. one is actually a bit irrelevant but modern one is is probably uh will demonstrate the the case that we are having or talking about multi- chains. So and later we will see that if we need to use this kind of uh contract we need to validate that this

uh contract support this specific chain. So we have a router. So in this case this router can be used in order to fetch the contract to execute to use it for uh any any other type of of uh uh execution that involve with this router. Um so once this is done the next step will be to create an action. So you know that we're going to have uh we we're going to go for ad liquidity right and as you can see ad liquidity has a lot of um uh parameters so I'm going to skip that like doing this like manually I'm going to check it out over here and show around that how it's look like how the action should look like. So

we see that it's inherit from bay section. Base section means um an interface that eventually have encode call that will get you the uh encoded uh call data to be executed. So and it's going to be like also a map of uh um of call data. But in our case once we want to have such an implementation then we'll see that um we need to fetch first all the parameters that we need okay on the constructor that that means the router of course um the receiver address okay

uh token A token B uh amount desired for NB if needed min A and min B that as part of the um the ad liquidity uh um call and a deadline. Um in that case once we have it the encode calls actually means to format this as um as a um as an encoded call object and get the exact execution on its way. Of course args will be the same order as we know from the contract itself. function name very straightforward and it's actually supports um VM uh SDK as we know so that should be like super

transparent to any uh web3 developer and should have it to you ready to use very very simply so again back to what we had we had a multi multi-chain unis swap router uh defined we had the unis swap uh uh liquidity action in place that means uh get me get me the parameter And from that point I know how to uh encode um uh an EVM um standard call. And once we have that now we can use it and make this uh thing a function.

I precreated um a test for it. If the voucher was then that will be whatever and from nothing was like one delay >> that will be in a way going to take us as I mentioned through um the entire journey crosschain from USDC uh from arbitum and USDT from base uh to Ethereum and then um deposit or add liquidity into unis swap.

So basically putting such um uh execution in place should again be something that is very straightforward to who is involved in the blockchain space. Uh we create a builder that is the most fundamental uh element on EIL uh execution that is already there and of course an account that represent the user account. Later Evo will show us how it looks on the UI and how Ember wallet implemented that uh for the users and the parameters that we want to have amount amount desired and for token A token B deadline as we saw parameters this is for test reasons we're going to fetch balances before we

do the execution and after and see the balance change and now we're going to see the creation of a batch remember a batch represent an execution on a specific chain um and can be involved with creation of a voucher. So here we can see um a create batch that is only involved with add voucher request. Add voucher request is an action. We we learned that the actions are actually the steps uh of execution on EIL SDK. So what we actually saying over here is that create a voucher of USDT token with the desired amount means that I want to take out of arbitum USDT on this specific amount and

later we're going to see also a batch that someone will claim it we [clears throat] sorry we're going to do the same for base uh and USDT creating a voucher a batch that involve with only a single step of creating a voucher for uh USDT on case and on that case what we will see is that we're going to see funds moving out of orbit USDT actually and use uh USDC from orbit and USDT from base >> and USDT from base um and what is missing will be uh the next step where we use all voucher. This is the Ethereum mainet uh uh batch creation and we're

going to see on that case use voucher means claim or get all the all the funds that were uh involved in the voucher creation on the other chains and we're going to see the funds uh moving into this chain and then we can use it. The next step for us will be an add action uh for approving USDC uh part of the the requirements for liquidity uh uh addition. Yes, it's a it's actually having the uh before that an approval for the two tokens that involved in this uh uh action. So we have an approve approval action for USDC with the relevant amount and we going to have approval action with USDT for the

approval amount. In this case, we we put max value, but definitely it should be set as like uh specifically what we uh want to have on this execution. And the last one of this action is unis swap add liquidity action that we just created with all the parameters that we mentioned before. um unis swap router account addresses uh USDC USDT as token A and token B amount desired min amount for both and a deadline we're going to execute that and see the balance change accordingly.

Now since we have a lot of connectivity issues we're going to hope for the best and see that running. Um, >> and I hope I didn't forget anything. >> Yes, of course I did. >> And second user is always control. >> Okay, we have that in place. >> Now let's run it. Make sure that it's functioning.

>> Hope network will be on our side. >> So, please talk to us if you want to exploit. >> No, it's not. It's actually uh failed for uh uh timeout. Anyway, we had all predefined some action that we I already run it before like an hour ago uh when I have a like optimal connectivity. Uh so, I'm going to show that instead. Uh and first this is um we part of the project of building stitch of and also involved with D5 implementation for EIL and extension we uh we created an explorer that involve with all chain

supported. So in this case we can see that we have the Ethereum mainet actions that are three of them. We see the approve two approvals and the last one is add liquidity. We see on base actually none just the the the voucher creation and the same goes for that is um voucher creation and approval for probably the related stuff. And >> now if we want to check how the execution look like we can take this

>> um this user ups without >> the TX hash contact TSH we before this uh we built the entire environment four chains on tenderly vinets that will be also used for the hackathon uh the EIL project on the hackathon and the ETH global hackathon. So we have it already and on that case we can see an execution on Ethereum and we can check for this specific >> thank you guys so much for coming >> handle up

and director >> of course >> okay we got it so let's shortly review what we have we can see that I don't know if it's likeis visible enough. But we can see that we have uh of course since it's account abstraction base, we see the entry point and we see the crosschain pay master and all of that. But we can see also that uh the null address this line is actually involved with issuing um liquidity tokens of unis swap. If we go to ether scan >> and put this one over here.

>> So you can see that unis swap v2 uh um token pool is created and transferred into the user. This is the the user address. The user also got on Ethereum a bit of USDC. That's because um when you uh deposit into a pair, it will take the the exact uh up to- date balance and if there are leftovers that just going to remains on the account um uh wallet. On this case, we have four and we see that all only 3.005 got into the uh the wallet. So in that case we had four some remains on the user wallet and some got into the unis

swap v2 pair. What else? Um we can go to dev mode and see like the exact execution but I will skip that stage that step and can have this um um like ignored for now. But as you can see we see that what happens on Ethereum uh uh on the destination chain that is Ethereum is actually exactly what we need. We had the transfers appears from the the crosschain pay master. we see that the deposit made into unis swap v2 pair uh and the same amount what we that we defined and on that case it's actually exactly what we uh want to have. So that's kind of it

for us. Um that means back to this um we managed to create exactly uh u a multistep involved with uh more than five um actions into this made it exactly the way we want to and it's a matter of couple of minutes. Of course, I know this is like I did it in advance, so it's easier for me. But imagine that it's involved with any basic fundamental um smart contract wallet involvement.

Now, if we're going to show us uh what we build with Stitch and going to take us through um the impact of this on um uh user experience with Mi wallet. >> Sure. Um so this is Stitch uh the app that offer uh implemented and it's the first app to really use uh the Ethereum interoperability layer. Uh and I'm from Ampire. I'm going to show you how it integrates with Ampire which is the first wallet that implements the Ethereum interoperability layer and the impact for users. So the cool thing about Stitch is that you can use balances across any number of chains uh without really caring about uh where this balance is. So it's essentially

balance consolidation. So the impact of this is that neither in your wallet nor in the top you're going to see uh fragmented balances anymore. So if you have USDC on five different chains is going to appear just like one USDC. Uh and you can see a perfect demo of this over here where balances are consolidated by network. Uh we have this very cool feature that we can actually peak into the underlying distribution of balances. So we can see that we have like a ton of different raptors, ton of different USDC's and etc. And by default, if I just use USDC from here, um, Stitch will decide or the Ethereum interoperability SDK actually will decide automatically uh where to use the balance from. But just for the sake of

the demo, um, I'm going to either like use all of the balance, ensuring that it hits all three chains, or I'm going to pick them manually. um to show you like the essentially the future. What I'm going to do is I'm going to allow it to pick automatically. So I'm going to enter 22. I have 10 on three different chains. So 22 must hit three chains. Um so yeah, it must use consolidation. Um then on the output, the cool thing about stitch is that offer already showed you all the protocols it implements and I can plug into any of those protocols. So I can say put my 22 USDC into a let's say now it's loading a quote and uh if the internet is good enough we should get we

should get it working and yeah uh and this is essentially a preview. The user doesn't need to care about this but each one of those arrows is a separate uh 4337 user op um and we have some voucher usage here as well in order to consolidate those balances into Ethereum. You can see that we essentially use USDC from three different chains. I know it's it [clears throat] might be a bit tough to follow but what happens here is we take some from optimism we take some from arbitum we put into ethereum and then we put them into a so now when we click submit this is going to start loading a request to umpire wallet to authorize all of the user operations at the same time um it's going to take a while uh again because of the connection but hopefully what we're going to see here

is a dialogue from buyer wallet uh showing you to authorize all three user operations at at the same time. And at the moment, it just shows hashes, but clear signing is coming. And this is going to show you uh oh yeah, it's working. Uh this is going to show you exactly what you're signing in the future. So it's going to tell you exactly what you're authorizing uh with the simulation as well. So it's not going to look like this. Uh but then when we click sign, uh this starts working and essentially all of the user operations get broadcast using the respect the respective bundware on each network. gas is paid only once even though we are doing connection across three different networks. Um and hopefully if we get this confirmed we are going to show the EIL explorer.

Yes, we have a link go to explorer and when this loads you're going to see all of those operations across all of the different networks that we just interacted with. So yeah, here we have a preview the same schematic that we saw and we have the raw code data on Ethereum, the ro code data on optimism and I think we had one more chain involved. Uh yes, optimism and yeah we can see it each individual user op and how it translated to an individual transaction. And obviously we can check this in scan if we want or arum scan or whatever. So yeah, that's pretty much it. It feels like magic. Um, it's pretty fantastic. Back to you,

offer. >> Thank you. >> Cool. Um, I guess, uh, we pretty much covered anything. Probably going to go to, uh, questions if there are any. >> One over there. >> Yes. Going to put this. >> Yes, please. Uh am I audible? >> Yeah, you are. >> Okay. Uh so on your example, I see that uh you're trying to uh move $22 worth of USDC and you're putting it into a am I am I understanding that right?

>> Again 22 uh USDC and to put it where into a Yeah. >> Yeah. So I see that there's only $12 is is the So 10 + 2 makes it 12. So another $10 worth of USDC is taken from Ethereum chain itself. >> Um yes the the idea is we have uh 30 um and on that case we're going to have 10 each. That's the original uh state. So what we did over here is to translate uh to actually transfer 10 from uh um optimism and two for from arbitum into ethereum and then you got a um uh the rest of it moving from uh it's actually three uh 30 on that case and moved this

all of it into uh um into uh um it's actually no it took already 20 just 22 but it took it from uh arbitum and optimism Okay. So, it's actually not involved with the the the funds that were in other places. Does that answer your question? >> Okay. Uh but I think my understanding was that you are using >> By the way, I'm assuming the amount could have been a bit confusing. So, essentially you had 10 in one chain, 10 in another chain, and 10 in a third chain. And I I showed 22 in order to show a real world scenario because 30 is like too perfect. uh because 22 requires taking two just from one chain in order to be to be able to to get that amount

because if it was 20 then it would hit two chains. Anything more than 20 hits three chains because we had 10 in each individual of the three chains. So I wanted to show a real world example of how consolidation will work. >> Maybe you want to have the the mic from him. Even if he has the mic, I don't have the but it's fine. How >> I was thinking um how does the chain that like is there a preference of like we're going to take 10 10 and then cuz like you could have taken two from optimism and 10 from arbitrum. How does that happen like alphabetical order in the list of >> I'm personally not familiar but

>> I will explain this is like >> EAL and that's something that can be a bit confusing. E is not like an intent solution. It's not building the logic for you. It's actually providing the the infra to uh navigate funds and do this all beautiful one single transaction multi-chain execution. What we build on top of it is to uh is to extend the building blocks into more D5 protocols and you can see that um over here. Um so you can see all the chains that we already supporting uh and actually all the different protocols but the logic is actually built on top of uh EAL us saying that if you have funds on a specific chain maybe

it's better to use it in order to uh to save the gas or you can uh define specifically what you want to use. So the logic itself build on top of it. I would say that important to uh it's just like a way for us to demo. What is important is that it's the the infra the EIL SDK makes it super easy to build something like that and let you focus on your exact logic or what or the use case that you want to support and not dealing with gas and crosschain and failures and uh and multi- signatures that are not available like mostly on on any other case and so on so on. So the idea is that you can build this logic uh like more properly. So what I was going to

say is that because I've been thinking about this from a wallet perspective and how to best consolidate it. Obviously you want to start working from the the the destination chain. So if you have funds on the destination chain that complicated. Um, are the docs going to be up in time for the ETH global hackathon on the repos or we we really got to dive deep and figure it out?

>> So, can you repeat the question? >> The question talks about the documents of uh EIL. So, it's already here. It's already published. It's this morning. Um what is missing probably like a tender integration that we going to have uh because we build for you uh uh up-to-date environment running uh but we also going to have like an additional documentation or or of how to run your environment your tenderly environment and play with that. So uh it's mostly there. I guess it's uh probably not perfect because it just launched but uh we're going to be there anyhow and we plan to have tomorrow session of

explaining how to work with that and what can be done with this and capabilities and what is support and so on. So make sure to be there and you're probably going to get all all answers to any question. >> Perfect. And one final question about uh the stitch and I kind of asked this uh yesterday. Um and I the answer got cut off and sideways, but um I guess I was thinking like how does the EIL be aware of like the current value of all of these things and like the quoting or like getting the best price from the wallet standpoint? You have to use something else to do that. Like can you give me an example of like is that Siri on like just help me give me >> for sure stack. So he's asking about like the the data like stitch is using.

I'll answer that because like uh probably more relevant. >> Um you can see I guess it's like now very common to uh have to split on any um uh web three uh related app DAP execution to actually split read and write if we're going if you if we are treating blockchain as a database read and write are separate. So in that case um you mostly deal with one of them in that case. Uh saying that because E is actually for execution. You won't see here any uh code or like balance between uh um unis swap pools and so on because the idea is to deal with execution

single signature as I said having the ability to support easily any protocol having like the best experience and so on. Fetching can be done like in any way that you can imagine. In that case we use like very common uh um uh data providers like um in that case it was um um um uh alchemy and uh and and so on. So it's mostly getting the data as as as you can there are some like we on this on stitch we tried as much as we can to base our data uh on onchain data. So it's uh I'm saying like um um as a service um alchem and so on but uh but

for us the idea the ideal is to get the data onchain but in some cases you cannot do that. Okay problem start by the way or when you um u you can miss stuff is when you get uh all kind of protocols that are not really onchain. Okay. You see for example, I will show you something. You see for example that we do support Limitless. So you can see any uh scene um or any market I don't know how they define it on Limitless is supported but now Limitless move to uh to walk on a different mode when you talk with their service and not directly with the smart contract. On that case we have uh with EIL there's no value with

that and that's very obvious. So it's kind of unrelated to that. So in this in this example, you can see that we only support the the onchain um element that involved with the uh limitless. >> That's perfect. And one final question, the EIL explorer URL I'm explorer.syndica dot is it? >> Yeah, I will share it on also this one. I will share it on the commentation. Um this is like something Syndica voluntarily did uh in order to support this project. Um because we want to have um some kind of an explorer that involve with multiple chains and batch

execution or like present execution that kind of unrelated. The connection between the batches or the transactions, user options so on is not really um um onchain. So you cannot match or connect them like properly. So we built some basic UI just to get it in place. I'm going to share it to you. It's going to be available. Uh it's very basic. We're going to extend that into something like more fancy having the ability to uh define the transaction of um voucher creation or voucher uh usage and so on. But for now, I guess it's a good start to direct you into uh the real explorer and so on. So >> cool.

Hi there. Um, I >> maybe not directly related to EI, but I'm having trouble understanding the relationship between EIL and OIF. >> It seems EIL is at the bottom of the stack. Provides a very simple intent solution and more complex intent based solutions are in OF. Is that is that correct? So I uh I'll tell you my my point of view about it. Um because that was mentioned also yesterday when we introduced uh EA for the first time. Your confusion your confusion is actually uh coming from EIL ability to uh support intent solution

very easily. So since it makes it uh super easy, it's it's put you in a position that it's a bit confusing. there's like not much more to do in order to get you an intense solution. Actually, stitch is an intense solution. You are saying you want to go from here to there. There's like many to many and and the magic happen and it's built u with um with the UI only like a logic that runs on a Chrome extension. Um in that case, uh EAL is actually the rails for it. It's actually the highway that you want to go through and all the apps uh are the cars that like that that riding through that uh highway. Um intent is only one of them. Okay, I

guess that's like the definition for it. But it makes it easy for uh building such solution. I guess that's like the bottom line and the most important message that can be provided here. >> Got it. Uh so I want to add something about this pretty much kind of the same perspective. They're complimentary. Uh by the way everyone is asking about this so it's good to clarify but there's no simple way to clarify without understanding each system in detail but the thing is uh EIL doesn't remove the need for intents although in practice because it's this multi-chain execution layer first of all and second of all because it provides a way to move funds across chains those two things combined uh lead to some to to intents being less necessary and a classic uh like third

party over being less necessary. So in a lot of ways the wallet can become the solver or the Dub can become the solver and EIO gives you better primitives to do that because if you don't have the primitive for multi-chain execution uh then it's really easy to uh shift this to an intent engine and a third party over uh and to just uh rely on this solution but uh one example is if I want to bridge once to another chain then on the other chain buy an NFT and then send the NFT to someone else. Those are three separate actions and nowadays uh if I want to do those three separate actions with just one signature uh then the best way to do this would be to depend on some bridge which has post operation hooks. Uh and this bridge is definitely

not completely trustless because uh it has to execute some code on behalf of me on the destination chain. Even if I authorize this code uh it does have some trust assumptions. uh and with the EIL the ability to execute those operations on multiple chains with the same signature removes that dependence on this third party bridge and also the ability to move funds between chains with the voucher model also eliminates this need. So in many ways it eliminates the need for a classic intense system but in many ways also you can think that first of all the wallet becomes the solver the D becomes the solver uh and finally some elements of uh the um interoperability layer are intense in themselves like the crosschain uh

crosschain pay master is kind of an intense like system the voucher is also kind of an intense like system. So yeah, they're really it's really hard to explain, but they're complimentary. >> Great. I guess we are done. Thank you everybody. >> Thank you.