[trustless://interop.landscape] Workshop - Building with EIL

Transcript

Uh my name is D. We worked on the uh EIL and I'm going to present the EL SDK. Erh a quick overview. I know you probably heard it. EIL is a crosschain protocol to do decentralized uh token transfers. And the SDK is the tool that you as a developer can uh create an operation that spans multiple chains and it abstract away all the logistics of moving assets from between different chains.

>> So this is the SDK. Uh you can start download it now and you can download it later if you want to try. We're trying to I will try to explain the APIs to explain how it works and uh maybe walk through and see it the application runs. >> Uh okay. What is the SDK? It is a TypeScript library that lets you uh do all everything you need to do to make a crosschain token transfer with the uh protocol. And so the open >> this is a overview of the protocol the basically the classes that you're

running with the protocol you start with the SDK the SDK is the wrapper the overall wrapper that you work with now in order to create a a crosschain operation you bring up a builder >> you create a a builder contract uh >> and from it you uh spawn multiple uh what we call batch builder. A batch is a set of operations that you run on a single chain. Uh we are using ERC 4347 obviously underneath. So each batch is eventually a single user operation that runs on a single chain. So you create multiple batches one for each chain that you want to run. Each uh

within each batch you run an action. An action it basically it's a single call. Again it's a bit abstracted. We will see it later. uh you can have a simple method call but we also a higher level like token transfer and uh I'm not sure if it's here or here they created with the stitch project if you seen yesterday they created multiple defy actions like uh I want to lend I want to use specific for specific protocol but basically an action is a wrapper for a method call or a set of method calls that you can use once you created use the uh the the the question batch builder and you create multiple batches.

Uh it's time uh to execute them. So you first uh build all the user operation out of these uh batches uh which requires checking checking that there are providers checking that you the balances across the chain and then you hand that out the output to the what we call the executor. Uh the executor is a contact that runs these user operations like executes the first user operation, waits until it's executed or failed, probably executed successfully. Uh and if this user operation requested a token transfer to another chain, then it waits for the tokens to appear on the other chain

through the bridge and execute the next user operation. So basically it wrapped everything but it's a single execute call. We will see that uh these are the core contracts of the SDK itself. We have multiple helpers since everything is multi-chain. So we have a multi-chain contract. It's a wrapper that uh around a contract that can have multi different either the same address or different addresses across different chains. And obviously the most useful one is a multi-chain token. We have one in the sampler. We see we have USDC on multiple chains and uh we also have USDT on multiple chain and you can bring up your own object with multiple addresses.

The idea that you usually work with this multi-chain object and you don't really care its address on the current chain because when it is added to a batch it will use the right address. Ah and of course the account itself you as a user have an account so it is a multi-chain account. uh it's a wrap around a smart account that and it manages all the uh interaction within the different chain manages the nonses on the different chains everything when it needs to deploy and everything uh if I make uh contrast it with how you used to work with user operations and even transactions before the SDK. So you would need to create an instance of a smart account for every chain you are working on. And the same it will go for

a token. You would have a set of configurations for every to every token on every chain. And the same goes for uh an action. You would like have to build a batch action if your smart account supports it for a chain and then you would have to repeat this action again for a different chain. So here we allow you to do the building once and sign in once uh using the appropriate classes and appropriate uh applica like APIs uh for the crosschain operation and the difference is like crosschain is when you actually intend to do something across the chains and the multi-chain stores the data that spans multiple chains for you to use in your application.

>> Okay. And uh we are talking at the API level but at the UX level obviously the most important things that a multi- channel smart account we wanting to do is sign at once all the all the user operations. Uh a simple one if you have a private key it's very easy sign for all because there's no UIX so there's no UX even to sign multiple times. uh we did some work with empire. So you will be able to do a single signature on a a single dialogue to sign all the user operation and then you can run them through.

Okay, I'm now going a bit deeper. I'm I'm going to see uh to show how we're using the SDK. The first thing you do is you bring up the SDK. uh it can receive parameters in order to define what chains it is connected. At the moment it is connected to a we brought it up on a test net actually on a tenderly based test net. So it has four networks. It support Ethereum, arbitrum, optimism and ethereum. So but you can bring it with more. Right now it is built with these four. Uh I create my account. I create my multi-chain smart account and I pass it

the the owner the that will be the the entity that will that is signing for them all and uh I create a builder. We'll see in a moment how I use the builder to create all the batches inside it. And also we started for this sample er we create an instance of USDC I assume I think I put it in into the file the token file uh which actually I don't I didn't put it into the slides but basically it's an array of chain and address

>> I need a list of chain and addresses this is what I need from a for a token file from the SDK it connects to the connected networks that the SDK is currently supporting. >> If I may, uh so uh I don't know if the future flights will elaborate on it. Uh we can see here that we create an account from the private key. It's like one example that that would require like your u application to have a a direct private key. But the uh account class here when it's passed to the builder, it's just an interface. So either you can implement it or wallets can implement their own account proper. And we will be shipping with a number of account implementations uh where it can be using like your injected uh account

for for sure. So like you you you need to prepare the multi-chain smart account with the appropriate API and then you build pass it to the builder and then this account will be used to control your multi-chain execution. >> Yes, the presentation I built around a command line application that uses this multi-chain account and actually it's a simple one. It's signed separately using the owner. Erh we do have as I said earlier the the Ampire account that can connect underneath and it has a UX and then it prompt you once uh to sign all the user operations.

Okay, this now now we're seeing a batch. This is a sample uh batch that I we created with crosschain builder because if I show the API of the crosschain builder it's a single function uh start batch uh so in this example can you see them? Yeah see my uh I started a batch on a specific chain let's say arbit room and I want to perform some actions on this chain. Erh we'll go deeper about the actions. You can see I added a transfer action. I give the token. Again, it's a multi-chain token. I don't care about the address because uh the batch will run on a specific chain. So, it will know what address to use. I trans Oh yeah, I forgot to fix it. Of course, I

cannot transfer to zero address recipient. And I specify the amount I want to transfer. Uh it could be this is a very simple uh simplistic example. Of course, probably want to do some DFI application. I al you can also call some erh make a function call on whatever contract you like erh and pass it the parameters and now we're getting to the juicy part I want to do to perform some operation that will go to a different chain uh this call with the voucher request the the model that we have is that uh you make a voucher request it's a call you

make onchain So it is an action basically it becomes a an action just like any other action like tokens run or whatever a voucher request saying I'm locking these tokens on this chain a list of token here is one and I specify what the destination chain I want these tokens to come. Erh this is a call I make to the uh contract of the EIL onchain and uh uh and it will make make a call and lock this for a period of time like 1 hour uh onchain. Uh this is also the end of the batch. Usually transfers you usually do at the end of the batch after you're

doing some other stuff. Should have written a better example before that like swap something. So I end the batch and I start a new one. The next batch uh not surprisingly is running on the same destination change of the voucher. This is a simple flow. I go one after the other but a flow can be can span more than two and I started batch of the destination chain and I specify that this batch should start uh should use this the above voucher. I have the ID of the voucher. I specify I use the that voucher. Uh this will tell the SDK when we build everything that the second user operation first can only run if there is

a voucher if it received all the transaction. It cannot be submitted on chain because everything it executed later there's no another action in the example but can depend on the fact that the tokens were transferred the amount will be there. It is impossible to send to execute this code without these tokens arriving because using a voucher means I expect all these token to be here. It is impossible to do otherwise. Uh and another thing it means that uh we don't deeply say within this uh presentation uh is about gas fees. When I created a voucher, I also said and yes, I will pay gas using the first token I specify in

this request. Erh, the example here is still using zero gas fees. Uh we we don't deduct this value, but it should. And then it means that uh the uh the second user operation that runs on the second chain uh is already prepaid for like the fact that it can use this voucher means that uh the provider that I'm using agreed to pay uh for this voucher and I'll get the money with the voucher.

>> I just want to uh to clarify. Okay. So let's go one by line on on the sample code here. So when the builder okay that is the crosschain builder it starts a batch in our case a batch is just a set of function calls that you would like to call on a certain on a specific chain the soft chain here is just chain ID number nothing else just the simple chain ID number 1 10 doesn't matter the transfer action in the second line is a convenience call for for what we call an action that is an action in our case is just a wrapper for a method sig basically a method call inside an uh an Ethereum smart account, a smart contract. The third line is doing exactly, this is just a sample code.

It's doing exactly what this second line is doing. So the function call action is a way to show you that the function call is just an ar arbitrary call to a just a target that is in this case USDC address and the function name of what like what it does. In this case, the function name should be transfer and not call. But basically this is just an arbitrary way to call to call an action on chain. It can be any smart smart contract with any API that you'd like. >> I think I expanded before you came. >> Okay. Sorry.

>> Yeah. >> Okay. So I will say like the a you see uh like it can look weird but the fact like you can name your requests. It doesn't make any sense here because you have two chains but you can build arbitrarily complex nested looped structures with the SDK. >> Anything but loops. like not very much looped but like uh >> it's a directed graph >> directed uh strcts and uh and then you can just select which vouchers go to each uh batch. >> Yeah. And in our case we just demonstrate one source chain and one destination chain but technically we allow any number of source chains and any number of destination chains and any combination of these.

One more. We keep saying source and destination when there's an example of two. But it could be a one, two, three, four, five listed. Again, someone skip the line. It can be a complex as graph. So for single operation, there's a source and a destination not for the entire graph. >> Uh I think some of that we covered on the previous time because this is a batch builder of a single chain. erh that performs the execution and uh pass a user operation pass action to the to them to build a so that eventually will create a user operation

>> yeah we don't have side I'm not sure we're going to talk it now but >> okay we don't have an example in this code snippet but as you can see in Third point, okay, we support runtime valves. Now, runtime valves, what it's supposed to do is basically if you don't know how much you want to send, for example, if you add an election in the source in the source chain that just swaps on unis swap and you don't know the exact output of this swap and you still want to use it for to to transfer it crosschain to the destination chain. So what you would need to do is do is add a runtime var action that basically specifies uh that you want to take the the balance of in

your account post swap. Okay, after the swap and then just use it and inside a voucher request. We we have a sample code for that in in our repo that we will show you. It's not in the snippet here. You add a you basically you add an action that uh uh makes a static call and save it into a variable and then any request it can be a voucher request but also any other request can reference runtime variable and then and use it uh and it's a value that is only exist during the execution of the code like usually a balance off but it can be anything Any method that returns a by 32

value can be used in the future functions. [clears throat] >> Okay. Okay. We talked about it. Action is an abstract method call. Uh internally implemented as an encode call. So encode call is very simple for simple functions. It can be more complex than that. So this is a simple action that we showed earlier. It's a transfer action. gets usually a token recipient uh usually an address again can be another multi-chain entity and using the addresses on this specific chain.

By the way, I forgot to say if anyone has a question or something is not clear, please uh stop me. we'll be able to clarify and uh this is an example of the implementation of encode call. Uh we take your multi-chain entity. You take the address under on the current chain. You receive the batch so you know which chain you this is encoded. The encoded is on a specific chain obviously. And then we return a an internal function call object which we clearly understand. It's >> what? Yeah. So what you see here is

basically the underlying implementation of transfer action which is basically doing what function call is doing but instead of instead of having the in the function call when you do add action when you need to specify all of these field here we just added a convenience function in in this case because transfer is so is so common that uh it can be used like that and we have several other conveniences like that but basically all of them can be used as a generic function Yes. And in many you can see this function. This is the place where we resolve multi-chain entities into the specific chain addresses. We can see that in this example we actually didn't the recipient is required here to be a

darus. It can be easily extended to be a multi-chain object. So you don't need to specify the address specifically when you're >> you do take the in the second line you do take the token address from other >> say I'm I'm we're doing it for the token but not for the recipient. So the token itself is always yeah it can be it's a sample >> and all one important thing to notice is that a an action is encoded as a sequence of calls not as a single call in many cases like an action will require for example approve so it is so you can create an array return approve this in that token execute what the execution maybe approve zero to make sure I don't have a

dangling approvals And this is a batch that defines what what the action I'm doing. >> If you go in the code later, voucher request is exactly that. Perform an approve and then make a call to the underlying function to do the code. >> Uh okay, this is another we saw it earlier. This is a a generic uh function called name. One thing uh to know that you specify a target you specify a function name the you can specify the API if you need and uh but uh a multi- chain content for convenience holds the AI so like this can be implemented this is a a

real implementation if because my contract can hold its own AI you don't need to specify specifically for each call >> okay now we're getting to the part that we have the execution The cost executor takes all the batches we created and convert them into user operations. It also takes all the vouchers and validate them on the destination chain they have to make sure that they are providers that can provide them at this point. If if you for example using a a token that there is no provider that currently has a balance, it will revert before you even start doing anything. It collects the addresses

of all the provider that can provide the and put it in the the user operation and then create a actually the list of user operation to be executed. Uh everything I said is packed into this single function which is called build and sign. Erh it first builds the list connect all the chain collect all this information and then it triggers the uh accounts uh sign I'm not sure we okay the multi-chain account we added a function which is called uh sign user operations it signs all them all all together and uh and said we are defining an an RPQL to

support it we worked with ambier so on ami it will pop you up show you all the user operations. So, we'll be able to sign them together. Um, and then after you finish to build and sign, the next thing is uh to execute. Execute is a multi-step operation. It's not that you just wait for it because at the minimum for transfer uh you execute a use operation, you wait for it to complete, you wait for a voucher. uh you submit the second user in wait there are at least five steps and uh as we know if anything can go wrong it will so you have at least five places that uh can

fail you do want to know where you are at the minimum to show a progress in the UIX so we have a callback that gives you all the information you have uh the index you created a sequence of user operations so it's a sequence number of of your batches uh type the most important of course it's failed but uh we can see internally the the other cases like created the user project we submitted the user patient we're waiting for a voucher we just received the voucher great let's continue to the next uh and uh you have the transaction a once user person is there and chain ID ah a user also contain the chain ID there is a question

yes >> I question Yeah. Can you give me a microphone because I cannot hear >> um I just had a question about the crosschain executor. You're saying each batch is single chain but you can put together multiple single chain batches to execute crosschain with the executor. >> Yes. Right. >> Okay. Okay. >> The idea >> you don't have crosschain like the batches themselves are not multi-chain. >> No. >> No. Okay. >> Okay. So we have crosschain batch which all the batches and for each chain we have >> so let's go over let's go over the structure again the main the main uh the SDK has as the main uh class the crosschain SDK which gives you a

crosschain builder now this crosschain builder you can start with it like I think you start with start batch or create batch I I don't remember start batch and that returns you the batch builder now this batch builder you can for a single chain now so It's two layers of uh two layers of builders. One of them is building the crosschain batch the crosschain operation and uh each crosschain operation has a batch builder that builds for a single chain. Okay. So in this case this builder is actually the one that is the crosschain builder.

So after you do okay after you start batch okay and you added all the actions to the batch then you start another batch for example for the destination add all the actions that you want the voucher request using voucher from the from the source then you do builder build and sign that is the crosschain builder that returns you an executor okay so in this case you already have all the user operations on all the networks uh built and signed and the exe the executor as draw right said except a call back that right now this call back is very simple but it can do much more elaborate things and it actually is missing some fields here for conveniency that that we added just for you to be able to have more information you you

will see them in our repo it's they are well documented the the fields that the the callback is getting but yes so you have a crosschain builder that gives you single batch builders single chain builders that are the batch builders and they return you each one of them the crosschain the the user operation and eventually you have the the builder that builds all of them together builds and sign and yeah that's it uh that's okay this is okay some helpers on the mult tokens I want to show you a demo of this application >> sorry yes >> um so if we have like uh

>> just a second >> in that in that simple example you showed where it was just like a source chain and a destination chain. >> Yeah. >> On the simple example you showed where there was just a source chain and a destination chain, you had the like uh add voucher request like you added one voucher. If we were to like have an extra chain in there, you would need to create another voucher for that second chain. If you wanted to do something like >> Yeah. Okay. So, if I'll give you an example. So, suppose you have multiple source chains, you can ask for vouchers on all of them. just add voucher request on all of them and then first of all this voucher request is is designated for a destination chain. So if you have one destination chain of course all of

them will be for one destination you still have to specify the destination for each voucher request but then on the destination you can do use all vouchers which is a convenience to just use all the previously uh requested vouchers or you can do use voucher per voucher that you are calling and if you are calling with al also multiple destinations then you just need to to specify for each for each destination the source vouchers that you're using as as I said >> okay I'd like to uh uh as an example, think of if you have a blob for all the actions you run on each chain and then you are a voucher is the arrow. It's a request on one chain, destination on another chain. So you can have just two

with an arrow between them. You can have three in the list. You can have one that spend multiple requests use on different chains and collected into one chain or going elsewhere. As long as this graph doesn't create a circles, it's okay. It it is okay that the same chain will be used twice. For example, if my flow means move my tokens to another chain, perform an action there and move back to the same chain, it is possible. It's another batch on the source chain. It is okay from Yeah. And and that's where you were talking about if you don't know what the amount that it's going to be after the chained operations. This is where you can set a

percentage with that variable. So for example, if you have I don't know if you have a very good aggregator of DAP aggregator sorry some some sort of a DeFi aggregator that you want to use for example for elaborate swaps and you have the best uh the best prices for USDC to ETH on on arbitum but the best prices of repped bitcoin to to on base then you can do all of these elaborate swaps in like from source to destination then back to the source and we don't enforce any uh any restrictions on this uh besides again for this this graph to be a cyclic just in order for us to be able to resolve it. But yeah, that's exactly what we what we aiming for.

>> We didn't say everything we do in EIL is the same token. >> Like you're moving the token can have different addresses but it is the same token. You're moving your tokens from one chain to another. We don't we are not handling any uh h pricing we don't have oracles because it should be the same value they you can build different protocols and on top of that but when we are saying swapping and that you you always go use decks uh for doing all those >> okay we don't prohibit sending an asset uh one asset to a different asset on different chain we just don't uh natively support it in protocol so it's not that we uh enforce that they are not

the same. We just don't have any way to know whether they are the same. Okay. So that's why it doesn't >> and as a small thing uh like you can actually move this variable across chain using a special like key that you can create uh in like you create a session key in your in SDK and that allows us to uh append not only the u the voucher itself but also some extra data. So you can create a random variable and move it across chains and resolve the uh for example the price of a swap on optimism.

You can move this data next to arbitum even if like you didn't know that and you don't need to use an oracle or message passing. It's just a part of the SDK uh session key. So like >> we have session data >> session yeah session data is assigned data of it's a >> session data is a I'm not sure we'll be able to go into session data this is a sample program uh that we have actually it's the sample program we copied to into the >> so to to simplify I I think to simplify the flow um if you guys were in yesterday on any of the any of the talks about EIL so EIL mostly focuses on on

two or three things. One of them is crosschain asset transfer. The second is multi-chain execution and multi-chain gas abstraction. So in our case the crosschain asset transfer is simply uh add voucher request and use vouchers. This is literally the crosschain asset transfer. The multi-chain execution is adding arbitrary actions as we could see on all the networks and the Gaz and the Gaz abstraction comes from the native from the protocol where you pay with with the first token on uh on on the voucher request for the gas on all on all the destinations that you're using.

So you can pay with one token on all the on uh on the execution for the execution on all the networks. >> Okay. No, I just want to see if I run this test program. >> So, it starts building everything. Uh, >> this is my account. It created the batches. It doesn't take it's synchronous. It doesn't do anything. Now, it's building the user operations. It's a bit slow the network, but it works. That's good. Uh, it executing the graph. We are seeing they execute the first transaction, completed the first transaction. It waited for a

voucher. The voucher was issued. Now it's executed the on the destination chain. Um it doesn't show much better if in terms of her progress. I >> the demos yesterday were better in terms of what they showed. But this is just to show the the code that run the SDK itself. It's not about the demo. >> Yes. And it timed out. Sorry. >> Never demo. >> Is that uh CLI CLI example code on the GitHub or is that on your GitHub?

>> Yes. So everything draw currently runs is on GitHub. We have we have actually other repos as well that we are going to to provide you with links for. I'm not sure that they are in this uh presentation but we will provide them we in our GitHub repos. And you can see all the all the information, all the more elaborate examples for what we did. And uh hopefully you can build up on that. And if you have any questions, of course, come to us, ask us. We are here. >> We have a demo with React and VM and we have a CLI demo for like different.

>> Yeah, the demo is working both on Sepia on Sapolia's networks. I think we deployed on arbitrum base and optimism and of course mainet sapia and it's working on on our devet from tenderly thanks to the tenderly team that provided us with the long long-term devet that also has more elaborate tracing and all the features that you know from tenderly >> with the idea with the tenderly it's it's a fork of the network so you can use more for whatever exactly you can use something you can't do on a >> yeah you can use all the all for example the unis swap addresses and compound and whatnot

>> and stitch is like a full-fledged like defy platform working with the internally just pure >> stitch app yeah >> the stitch app yeah >> um >> yes >> sorry >> it is not in the infin infinity repo they have a stitch app repo I I will get the link we're making sure that it is link Any more question if we want? We talked about runtime V. Let's say let's say that not it will work but >> sorry for runtime v what you do you make

a call to a transaction to add it here >> actually I >> sorry I'm not [laughter] >> don't don't go doing doing a sample we have several samples of runtime bars and how to use them we don't have to show it here but I think that while it is complex because it's a more complex concept here but it is still relatively intuitive in my opinion >> yes the idea you add an action the

action It's a set var action. It makes a static call and save it into a variable and then instead of a variable you use runtime var. >> This will revert if I run it because it is not set but uh it will use it inside the the execution of the application. >> Okay. Um okay. In the meantime, are there any more questions? Something that you want us to elaborate on?

Hey, thank you for doing this. Uh, can you please show what is like the token uh token file where you get the USDC address from? >> Ah, yeah. >> Okay. >> I'm just wondering like in the case when you have fragmented liquidity. >> I have here >> the token file is simply an array of uh >> so it it's just arbitrary input, right? >> Yeah, it's an arbitrary input. >> Yeah. Okay. Thank you. just chain ID and others >> just some let me go a bit back about the an overview of the SDK there are a lot of things you need to do in order to do crosschain application uh like quering oracles all the usual stuff uh you need we uh the SDK is a concentrated on making the actual

crosschain transaction once you know what you want to do so yes we do need a set of addresses for tokens and we assume you have a good source for that this is not something we can provide. We cannot even attest that these addresses are correct. But uh if you uh specify invalid addresses like when you create a voucher when you pass a multi-chain token, you actually say I'm looking for this token address on my chain and I'm going to this token address on that chain. This is the value. And if it's a wrong address, then probably no provider will execute it and you'll time out because it's not a valid or if you just like you ask an invalid

token. We're not validating the token but >> so we do assume they are the same address because there's no pricing queries here. So they should it should be the same token the same the same value. So a provider will accept and do it. >> Okay. Thank you. Yeah, and like to touch on the question about like fragmented liquidity. You will be able to collect your liquidity using the AL. So it's not as fragmented anymore. You just create multiple what we call voucher request and you have like multiple source chains just a single destination chain and then you can collect like a 100 different chains into one and uh just wait a little bit

for every all of them to arrive. >> Okay. Yes. And the uh the SDK right now is mostly the primitives. An example, if you have a fragmented liquidity and you want to use I want to use my USDC, we can create a set of batches that run your USDC from whatever chains you are and do some operation with that. Right now it is manually. you need to know on which chain and run a a batch for each of those chain to collect it to one chain and do the operation like you do it in your DAP. We do want some of this to yes to to to have a helpers inside the SDK. So actually for uh touching the helpers as you said this

SDK that we are showing this is the pure EI SDK that should do the basic stuff the basic things that we showed you [snorts] but there are there is already for example the stitch demo the the stitch app that offer showed yesterday. They built on top of this SDK another SDK that just wraps and gives you more convenience methods for swaps for different DeFi actions that you can use and just as as more elaborate primitives instead of just implementing them yourselves. Okay. >> Uh the the stitch Yeah. The stitch we need we need.

>> Yeah. Yeah. We >> we'll find it. We'll send it to you. join the discord and we will share the the your own discord. >> Yeah. >> What we have discord >> we we will have a discord. >> No no is kidding. It's kidding. [laughter] We have a discord. We have an account of talking >> and like another small thing like the >> technically our organization discord. We have a discord. >> We have a discord. Don't worry. [laughter] >> We cannot advertise >> and and we also have it already in GitHub. It's just that the uh offer that built the the stitch API, he put it in his own uh GitHub repo, but that's that's okay. It's also public and it is accessible by anyone. So, we will just post the links in our in our GitHub and in our discord and you can use that.

>> Yes, someone behind. >> Yeah, sorry. >> Uh here is a discord link if uh I don't know how to put it on the screen. [laughter] Sorry. >> Uh for something like uh a crosschain like token transfer >> um on the destination chain there would have to be some kind of LP for like providing liquidity on that side, right? >> So would would there be like an LP like fee as well >> and something like said there going to be fees? Yes, there is an LP that listens everything that he everything you see here. There's no server except nodes. The the clients will connect to

the network. All the communication is done on chain. I request a fee by transaction and provider give it by issue a transaction on the chain. So I can take the voucher. >> I didn't go into the deep into the flow. >> Uh just okay to clarify because I think it's a great question. Uh there is a fee mechanism uh that is part of the protocol. It's part of the protocol itself. We just uh we just hid this fee inside inside the SDK because we have a in in our opinion a very reasonable way to to adjust the fees that but the the way it go is that the it goes it is a reverse Dutch auction that is the the client the user actually specifies the

fees and the the increase in time the fe how much the fee would increase in time in case the transaction isn't included. So uh it can for example just uh include a very small fee for the for the XLP for the liquidity providers and the fee will increase as much as the user specifies in case no no liquidity provider see that as profitable enough for it to include and it can also include a maximum fee that that uh that it will reach that it doesn't matter if time passes it will no longer increase more but basically the the user very much controls the fee. Looks like >> Yes. So you ask if there is a way to

estimate it. So yes, exactly. This is what we do. We already look for previous uh liquidity providers and see like the the average fees that they are that they are taking and we are taking something a little bit lower than that and post that as the as the reasonable assumption of what would be a reasonable fee in our case. Okay. So we put some reasonable defaults but it it is configurable. really >> um what happens if you create a voucher with too much value? Is there a refund mechanism at the end or like unused voucher amounts?

>> What do you mean? Okay. more than the like liquidity can be provided on. Uh like >> there's no there's a voucher is either used or not. Like if you put if you make a voucher request, you make a voucher request for whatever amount token. If no one accept it, you'll time out you will and you will be able to unlock the >> you will need to wait for a timeout like which is about an hour. uh >> to see about less than an hour the SDK will handle it event right now it doesn't >> withdraw this amount because it's yours and uh to continue without it if the voucher is used we showed here on the example of a voucher of a single token

but a voucher can be multiple tokens so it is either all this voucher is accepted or nothing at all so so there no unused voucher in that There are cases, there are edge cases like a voucher was issued, there was a real voucher, but your transaction that uses this voucher reverted. Now, this is an unclaimed voucher. It was already used. So, you cannot claim it on the source chain. The provider already can already claim. You cannot get it for yourself. What you can do and we will do is do a mechanism that a fallback that will either depending on what you want

create a voucher back to move it to the source chain or if you like you can continue and create another user operation to to run it from the destination chain >> like the money is never stuck like if if your operation reverted the money is available to you it's on your account just on the destination chain like the thing you wanted to happen didn't happen >> but yeah >> so at the so at the moment it is locked and you need a specific specific manual API we do the SDK will add it so that it will >> okay >> automatically or half automatically we'll get it back to you >> so we we okay to clarify the flow uh when you add a voucher request it literally calls a function that requests the voucher on chain this function transfers uh transfer deposits the

tokens that you want to uh to send to the other side in the crosschain EIL contract okay and this contract is basically waiting for an liquidity provider to call issue voucher. So if the if any liquidity provider issue the voucher for you then the wallet is going to take this voucher from the from the event and post it in uh uh in the user operation as we as we do with use vouchers. Okay. And that will that will then transfer the amount on the destination chain. Now if this voucher isn't used as sorry if the voucher request wasn't fulfilled then it has a very short timeout and then the wallet just can withdraw it again from the from

the deposit in the EIL contract. So it's not like it's locked only for the expiry of the voucher request which is minutes. >> Any more questions? Yeah, maybe added like an inspirational like we expect the wallets to do more and more integration with the EL. So like for now the SDK is written for the D but it's useful for the wallets and wallets can embed it and like use the features uh that we are providing but as uh as time goes we expect that to be more of a wallet thing to support Yale and for applications they may not even like need to like add an SDK and they will be able to use for example like send calls API to just like express

their like crosschain intention and just uh just use that. Basically we do expect that the application will do of course we'll do all the batch building because this is part of the application and the sign and execute will be done by the wallet. So so once we have that the SDK will almost stay the same but we'll use more of the wallet in order to do this stuff. It requires more to define the standard to interaction with the wallet >> for status for running the engine inside it. But so right right now we using the wallet only for the signature the

multi-chain signature and all the SDKs running on the application side. >> Okay, we're done. Thank you. >> Okay. Thank you very much. >> Another question. So, I heard that there was a docs page on a URL that dropped this morning, but I haven't been able to find it. It's not on the EIL SDK readme or repo, but I saw earlier like actual docs from a pre the earlier workshop. Can you >> We do have a docs page. Um >> I'm not sure about you. Where is it?

>> Tom Tom is here. Happen to be here. Where is the doc page? Like what is the URL? This was yesterday. Sole. >> Yeah, it was. It went live yesterday night. Uh, it's available at docs.ethereuminupplayer.com. >> No, do docs.ethereum interruplayer.com >> like this.

>> You can open it. I think you have a I wanted to get rid of the underlying. Oh, it's okay. >> Oh, you just Yeah, just do it. >> I could also open the Discord now. >> Okay. >> Okay. So while the SDK currently looks uh like with very basic building blocks as we said like for example every every uh developer that wants to contribute and add maybe a more elaborate building blocks and maybe use something like what the teach guys did that that would be awesome for us. We are accepting pull request for that and that would also

make the the effort for the community much better. So if you're using if if you're using a certain DAP and you are already implementing all of the functionality to actually batch uh reasonable uh reasonable calls to that uh to that to that defy then it would be awesome if if you could also open a PR for us. We will add it as an just a native block builder. Yeah. >> Tom, do you have any information about the hackathon? One second. Sorry. So, we do have

another workshop uh on Friday the 21st at 3 at 5:00 p.m. Workshop room 3 for anyone who's going to the ETH global hackathon. that is. And we also have a bounty uh three prizes, three 2 and 1K. Uh we're basically looking for projects that will take the EAL SDK and uh build cool stuff with it and demonstrate what you can have when you have, you know, trust minimized seamless UX.

Um so yeah, again, Friday, November 21st, 5:00 p.m. workshop room 3. Um thank you everyone. >> Okay thank you. We are sit here. >> Yeah.