trustless EIL SDK Workshop I Alex Forshtat, Dror Tirosh, Shahaf Nacson

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. uh EIL is a crosschain protocol to do decentralized uh 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.

Uh so this is the AL 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 it is a TypeScript library that lets you do all everything you need to do to make a crosschain token transfers with the uh protocol.

This is a overview of the protocol the basically the classes that you running with the protocol you 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 a batch builder. A batch is a set of operations that you run on a single chain. Uh we are using ERC 447 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 basically it's a single call. Again, it's a bit abstracted.

We 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 he's here or here. They created with the stitch project if you seen yesterday they created multiple defy actions like uh I want to uh 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 uh you use 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 out the output to the what we call the executor. Uh the executor is a contract 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 sample. We see we have USDC on multiple chains. And uh we also have a USDT on multiple chain and you can bring up your own object with multiple addresses. The idea is 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 and of course the account itself. You as a user have an account.

So it is a multi-chain account. uh it's a wrapper around the smart account that and it manages all the interaction within the different chain manages the nonses on the different chains everything when it needs to deploy and everything

uh if I make contrast it with how you used to work with user operations and event transactions before the SDK so you would need to create an instance of an smart account for every chain you were working on and the same it will go for a token you would have a set of configurations for every tok 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 using the appropriate classes and appropriate uh applica like APIs uh for the crosschain operation. 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 thing that multi-en smart account we want you 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 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 arbitum optimism and Ethereum mainet. 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 that will be the the entity that will that is signing for them all and uh I create a a builder. We'll see in a moment how I use the builder to create all the batteries inside it. And also we started for this sample erh 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 a 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 network that the SDK is currently supporting.

If I may uh so uh I don't know if the future flies 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 a the owner. Erh we do have as I said earlier the the Ampire account that can connect underneath and it it has a UX and then it prompt you once uh to sign all the user operation. 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, you see my uh I started a batch on a specific chain, let's say arbitrum, 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 addresses 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 D5 application. I al you can also call some uh make a function call on whatever contract you like uh and pass it the parameters. And now we're getting to the juicy part.

I want to 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 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. uh 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 the 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 that voucher. Erh this will tell the SDK when we build everything that the second use operation first can only run if there is a voucher if it received all the transaction it cannot be submitted onchain 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 tend to execute this code without these tokens arriving because using a voucher means I expect all this token to be here.

It's impossible to put it otherwise. Uh and another thing uh it means that uh you don't deeply say within this uh presentation uh is about gas fee 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 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 deduct

I just want to uh to clarify okay so let's go line one by on on the sample code here. So when the builder okay that is the cross chain 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 source chain here is just chain ID number. Nothing else. Just the simple chain ID number 110.

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 the 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 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 before 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

not very much loop but like uh

it's a directed graph

directed uh struct 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 example of two, but it could be a one, two, three, four, five listed. Again, come skip the line. It can be a complex as graph. So for a single operation there's a source and a destination not for the entire graph.

Erh I think some of that we covered previous time because this is a batch builder of a single chain uh that performs the execution

and uh pass a user operations pass action to the to build a that eventually will create a user operations.

Yeah. No, we don't have side. I'm not sure we're going to talk about it now, but

okay,

we don't have an example in this code snap snippet, but as you can see in the third point, okay, we support runtime valves. Now one time V was 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 after the swap and then just use it and inside the 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.

add a you basically you add an action that 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 a 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 by 32 value can be used in the future function. Okay. Okay. We talked about it. Action is an abstract method call.

Uh internally implemented as an encode call. 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.

That's 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 a 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 you understand. So what you see here is basically the underlying uh 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 fields 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.

call.

Yeah. And in many you can see this function. This is the place where we resolve multi-chain entities into the specific chain addresses. You can see in this example we actually didn't the recipient is required here to be a D. It can be easily extended to be a multi-chain object.

You don't need to specify the address specifically when you

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 an yeah it can be a sample

and all one important thing to notice is that 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 and 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. Go in the code later. Voucher request is exactly that. Perform an approve and then make a call to the underlying function uh to do the code. Uh okay, this is another we saw it earlier.

This is a a generic uh function called name. Uh one thing uh to know that you specify a target you specify a function name. Yeah, 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 real implementation if because my contract can hold it AI.

You don't need to specify specifically for each copy. Okay, now we're getting to the part that we have the execution. The cost executor takes all the batches we created uh 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 token that there is no provider that currently has a balance, it will reail 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 uh of course builds the list connect all the chain to collect all this information and then it triggers the uh accounts uh sign uh I'm not 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 instead we are defining and RPQL to support it and we worked with Ambi it will pop you up show you all the user operations we'll be able to sign it together and 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're executing use operation. You wait for it to complete. You wait for a voucher. Uh you submit the second user and 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 it's a sequence number of of your batches uh type the most important of course is failed but uh we can see internally uh the the other cases like created the user project we submitted the useration we're waiting for a voucher just received a voucher great let's continue to next and you have the transaction a once user person is there and chain ID ah a user also contain is a question. Yes.

Yeah. Can you give me a microphone because I cannot

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. You don't have crosschain like the batches themselves are not multi-chain.

No.

No.

Okay. We have crosschain batch 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 has 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 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 what you 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 cross chain the the user operation and eventually you have the the builder that builds all of them together.

with and sign and uh okay this is okay some helpers on the margin tokens I would show you a demo for 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 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 requests 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 I said okay I'd like to uh as an example think of if you have a blob for all the actions you run on each chain then you are a voucher is the arrow 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 You can have one that spend multiple requests use on different chains and collecting 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. Yeah. And that's where you were talking about if you don't know what the amount that is going to be after the change operations. This is where you can set a percentage with that

very for example if you have I don't know if you have a very good aggregator of DAP aggregator some some sort of a D5 aggregator that you want to use for example for elaborate swap and you have the best uh the best prices for USDC to ETH on arbitum but the best prices of re repitcoin to to it 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 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 are we are not handling any h pricing. We don't have oracles because it should be the same value. You can build different protocols on top of that.

But when we are saying swapping and that you you always go use dex uh for doing all those things.

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 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 an SDK and that allows us to uh append not only the um the voucher itself but also some extra data. So you can create a random variable and move it across chains and resolve the 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 key uh session key like

we have session data

session yeah session data is assigned data of the session it's a

session data is this I'm not sure we'll be able to go into session data Yeah,

this is a sample program that we have actually it's the sample program we copied to into the so to to simplify I think to simplify the flow um if you guys were in uh 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 Gaz 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 network.

Okay. Now just want to see if I run this test program. So start 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. A bit slow the network but it works that good. Uh it's 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 CLI CLI example code on the GitHub or is it not 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 uh 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 Saporia on Sapolia's networks which I think we deployed on arbit room base and optimism and of course mainet it's working on on our devet from tenderly thanks to the tenderly team that provided us with a 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 a focus the network. So you use more for whatever.

Yeah, exactly. You can use something you can't do on a

Yeah, you can use all the for example the unis swap addresses and compound and whatnot

and stitch is like a full-fledged like D5 platform working with the internally just pure

tap. Yeah,

the stitch app

um

yes um

it is not in the infin infinitive report. They have a strap repo. I will I will get the link. We'll make sure that they any more question. We talked about runtime v.

Let's say let's say that runtime v what you do you make a call to a transaction.

Yep.

Don't don't go 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 uh concept here, but it is still relatively uh intuitive in my opinion.

Yeah. The idea you add an action the action uh set var action 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. Um

okay in the meantime are there any more questions something that uh 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. That's chain ID and other

some let me go a bit back about the the overview of the SDK. There are a lot of things you need to do in order to do crosschain application like quering oracles all the usual stuff uh you need we uh the SDK is a concentrated 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 and 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

okay. Yeah.

So we do assume they are the same address because there's no pricing uh queries here. So they should it should be the same token the same val 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 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 USBC, we can create a sort 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. Yes. to to have a helpers inside the SDK. So actually for touching the helpers as you said this SDK that we are showing this is the pure E SDK that should do the basic stuff the basic things that we showed you 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 or different DeFi actions that you can use and just as has more elaborate primitives instead of just implementing them yourself.

Okay. Uh the the stitch Yeah. The

stitch is the we need we need

Yeah. Yeah. We 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 discord?

We we will have a discord.

No no kidding. If kidding we have a discord. We have an account of discord. Yeah.

And like another small thing like the

technically our organization discord. We have a discord. We have a discord. Don't worry.

We cannot advertise and and we also have it already in GitHub. It's just that the offer that built the the stitch API put it in his own GitHub repo. But 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.

behind.

Yeah,

here is a discord link if uh I don't know how to put it on the screen.

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?

Yes. Yes.

So would would there be like an LP like fee as well and something?

I said there's going to be fees. Yes, there is an LP that listens. Everything that everything you see here there's no server except the nodes the clients we connect to the network. All the communication is done on chain. I request by the transaction and the 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 free 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 XLPs 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 it will reach that it doesn't matter if time passes it will no longer increase increase but basically the user very much controls the fee. 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.

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.

You will need to wait for a timeout like which is about an hour about

less than an hour the SDK will handle it eventually. 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 only example of a voucher of a single token but the voucher can be multiple tokens. So it is either all this voucher is accepted or nothing at all. So there no unused voucher on that case. There are cases there are edge cases like the 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 store chain. the provider already can already claim you cannot get it for yourself. What you can do and we will do is 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 run it from the destination chain

like the money is never stuck like if if the 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 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

we we okay to clarify the flow

uh when you add a voucher request it literally calls a function that requests the voucher onchain this function transfers uh transfer it 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 uh issue the voucher for you then the wallet is going to take this voucher from the from the event and post it in 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. more.

Yeah, maybe I did like an inspirational like we expect the wallets to do more and more integration with the EL. 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 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 interaction with the wallet.

for status for running the engine inside it. But right right now we using the wallet only for the signature the multi-chain signature and all the SDKs running on the application.

Okay, we're done.

Thank you. Okay,

thank you.

Thank you very much.

Another question over here. 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 the earlier workshop.

Yeah, we do have a docs page. Um,

I'm not sure about your

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, docs.

thereum interruplayer.com. Like this.

You can open it. I think you have I wanted to get rid of the underline.

Oh, you just Yeah, just do it.

I could also open the Discord now.

Okay. So while the SDK currently looks uh like with very basic building blocks as we said like I for example every every uh developer that wants to contribute and add maybe a more elaborate building blocks and maybe use something like what each guys did that that would be awesome for us. We are accepting pull requests for that and that would also make the uh the effort for the community bunch 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.

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 or anyone who's going to the ETH global hackathon that is. And we also have a bounty uh three prizes 3 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 stood here.

Yeah. Thank you.