[trustless://interop.landscape] Mislav Javor - Composable Batching

Transcript

outlines. If we assume that a user wants to do several source chain actions and several destination chain actions represented by one signable trans transaction payload, we click quickly run into the issues of slippage and our next speaker is going to show us how we could resolve that. Please give a big round of applause for Miss Lav Yavore. Welcome to the stage. Good afternoon ladies and gentlemen. Uh it is a pleasure to be here. As they say, you always save the best for last.

So that's why they chose me. Um so I will be talking about something that's maybe a little bit esoteric uh you know in the programming terms. So what I want to do initially is show you a demo. I think we had an amazing demo by Orus uh today. This one is going to be equally amazing I hope. Um so as was mentioned um there is this problem of controlling for slippage in multi-chain environments right what we want to do is we want we have a position on one chain in one vault we want to supply to another vault on another chain we need to unwind the source chain we may need to swap the

token into some other token then we need to call the bridge then we might need to approve and execute and what we want to do we want to enable oneclick Ethereum. I think that was the entire point of this interoperability track and everything. And how do we do it? Well, I'll explain how do we do it. I'll show you how it looks now. So, this is a video. I would usually do a live demo, but the internet has been very cruel to me. Um, so what's going to happen here, uh, if you haven't caught it, I will be unwinding my Spark USDC morpho pool on base and supplying it to a Hyperweave HW HLP pool on Hyper EVM in a single signature and all slippages will be controlled for. There will be no

dust left over anywhere and I will have the most optimal price execution. So what's going to happen here? I'm going to get a quote uh from from in this case 7683 provider and I will tell you a bit more how this all ties into what Ethereum Foundation has been doing and what we've been doing in the uh Patagonia edge city for a while. Uh I will be getting this quote and when I receive the quote I will essentially approve and execute and this will start what we call composable orchestration. This will create a composable executable batch across two chains which will take the output of one function call and treat treat it as the input of the next next

function call. So what does this mean? This means that you are able to arbitrarily compose any amount of DI protocols across any amount of chains uh simply by writing front-end scripts. And in the video now I will go into this um explorer which will show us what was what has actually happened. You will see that the gas was paid in USDC on base and then that a transaction was executed on base and another one on hypervm and within the base transaction we will see that we have composibly stacked multiple function calls and use the output of one as the input to the next one. So why we use across here? Because across is the first implementation that allows this

composable bridging. But I'm happy to say that um in the um Patagonia workshop that we had last week uh many other providers came out saying they will be supporting composible bridges and not the least of them being our friends at the Ethereum Foundation. So it is trying to connect so I don't think I'll be able to do a slideshow. That's why I didn't want to do a live demo. So we'll do it like this. So what's happening here? Uh I will explain how all of this that you saw works. So uh what we will be leveraging here is ERC 4337, ERC 7579 and ERC 7683. So for those of you who are not math wizes and uh do not follow

ERC's like it's the latest ten nolla, I'll tell you what it is. So ERC 4337 is the smart account standard, the initial one uh that started all of this uh that we do at Bconomy. Uh ERC7579 is the modular smart account standard which enables you to add plugandplay modules into your smart accounts. And one of those modules is this composable execution module that was used for the demo that you just saw. And the last one is the ERC7683 which is the open intense framework that was um brainstormed uh last week a lot by us and our friends uh at um at Patagonia edge city with Ethereum Foundation. So what's the problem when

you are doing normal batching? Uh you have essentially solved only for one problem. You have solved for approve plus execute, right? You approve 100 USDC, you supply 100 USDC, all the information is known ahead of time. You have no problems. Well, what happens if you need to swap and then supply? Well, you can't because by the time you swap, the rate of the swap is going to change. So, you will not know how much you need to supply. The only thing you can do is approximate. You can query a deck segregator. You can query a bridging provider. You can carry query like all of these data providers and they will get really precise. I'm not saying that this is a bad solution in any way. They will get really close but they will

never get to 100%. But what happens then if you want to withdraw, bridge, swap, and supply. Assume each and every one of those steps incurs a 1% slippage. Well, now suddenly you don't have a 1% slippage problem. You have a 4% slippage problem. So even if you had great execution with 0.3% slippages, everything set up tight and you got six or seven steps composively, now suddenly you're working with 4% slippage and you cannot execute or I mean you can execute but you're getting such a shitty price that you rather wouldn't click that sign button. So um this needs to be solved.

It's it's not a it's not a good experience and that's why basically this front-end composable multi-chain DeFi doesn't exist today. Well, except for the demo that I just showed you recently. Um so as I said multi call batch execution are not enough because all input parameters must be known ahead of time. We do not know all input parameters ahead of time and slippage the most important and the most uh most worrisome of all is not known ahead of time. So with normal batching as I said you get dust you get suboptimal price execution and I really mean suboptimal price execution. All of you who are developers you know how complicated it can be to actually stack it up. You can solve this. Actually, all of this I just

need to put like some truth to it. You can solve it by getting the user to sign like 15 times. If you are willing to let your user sign 15 different times because you will control for the operation every step of the way, yeah, then sure you can do it. But if you want to enable a singleclick experience, you cannot do this without composible batching. So, and like yeah, okay, if you overestimate, you will have bad price execution. But if you underestimate your transaction will fail. So pick your poison. Either you pay too much or your transaction fails. None of these seem like super great options to me. Um so this is something how it actually looks. So if you go to this um composable super transaction we call it and it's using this composable

uh batching module you will see that I have fixed inputs and dynamically injected inputs in every single step of the batch. Right? So for fixed inputs we got okay I am using USDC and WE on base and I'm putting 2,000 USDC. I will be you can see it. It's kind of a bright orange color but it says swap contract on the top. So I will be swapping 2,000 USDC for we but then in the bridge solver contract. So I want to swap and then bridge in the bridge solver contract. I do not know how much I got from the last one. But worry not, we can set the amount parameter of the bridge solver function call as a dynamically injected input. So we are not fixing it when we are assigning the call data.

This is fetched from onchain information, right? It can be the balance of the token like you can just inject the full balance of the token. You can set a pre previous state of the token balance before the swap and then an afterbalance after the swap and then deduct one from the other and inject that. You can inject an oracle price. You can inject any piece of onchain information. And then the last part is after the bridge has completed I have incurred even more unknown variable slippage and then I want to supply to a supply to morpho supply to oiler or whatever and I need to use dynamic inputs there but then I use just the runtime we balance again on the destination chain. So what I have enabled with composable batching is a single signature fully composable

multi-chain transaction. We call it a super transaction. You call it however you like but it works. This is how it looks in code. Uh essentially this is an API call to our composible batching uh engine. You just say okay I am transferring to this address this like maybe is like a USDC contract or whatever but I am not actually transferring uh a fixed amount. I am transferring the runtime ERC balance. So this will be the balance within that very block. right within your very own slot within that block it will be completely precise at the time of execution and I am transferring that injecting that as the second parameter in that function call. So this is this

is how how easy it is actually to interact with composible uh batching. So as I said sources of dust in regular batching can be decentralized exchanges because of swap slippage solvers because of uh bridging solving slippage and they take their fees which can sometimes be calculated as bips. So you know depending on the number they might change dynamically and then you have this weird thing is which yield calculation precision. So some vaults and tokens acrue yield per block and depending on which block you actually uh pull them from you will have more or less yield and this sometimes cannot be controlled for easily if you are doing batch execution. So you will not know exactly how much you're going to get.

Now how do we do it in the background is as I said we use ERC 47 smart accounts ERC76 A3 open intense framework. Well, right now we also use the across uh wrapper that's uh that's uh available that does this composable bridging. And then uh we use the biconomy composable batching module for uh our Nexus smart accounts, but it's also compatible with any other ERC 7579 accounts. And we use the composable model of Bconomy super transactions. So I thought I had one more slide. Turns out I don't. Um that would be it from my end. I think I got nine minutes left over, but I don't have much more to say. So if there are any

questions uh please feel free. >> So >> can't do with the mic because do you want to just ask a question? Oh, that's a good question. So, uh the question was how is this user experience enabled? So, um the gentleman here asked uh whether we are using the ERC7702 to

delegate our EOS into smart accounts. Uh we are actually not. So, the idea is that this all works from a normal regular EOA. So, it's oneclick Ethereum for your five-year-old, sixy old, seveny old MetaMask wallet that you haven't connected or updated in the last uh half a decade. This will work. This does not require any type of u forward upgrades to your wallet stack, forward upgrades to the blockchain, forward upgrades. all executes on top of the blockchain using certain things that I think are a bit too technically uh demanding to explain on stage in the next few minutes. But uh yeah, essentially this this entire crosschain orchestration works uh

trustlessly. May may I add? There is no trust involved. There is no custody. There is no uh there is censorship resistance. Users can always force their own transactions. So by adhering to the highest level of standards of Ethereum, you can achieve these beautiful multi-step DeFi multi-chain flows with composible veting. >> Anyone else? >> Okay, >> thank you everyone very much. You are a great audience. Thank you so much, Miss Love.