[trustless://interop.landscape] Alex Vinas - CoW Swap’s Multiparty Exec and Cross-Chain Coordination

Transcript

Now, let me ask you, are there any traders in the room? Any traders? Okay, a couple traders. Those of you who aren't raising your hands, what what are you guys doing with your free time? So, the next session is going to talk about the struggles of trading. In a world of endless chains and scattered liquidity, users often face the impossible task of choosing the right risk, route, and timing for every trade. Our next speaker and his protocol are trying to solve that. Please welcome to the stage Alex Vinas from Cow Swap.

>> Thank you. Welcome everyone. Buardes. Thank you for taking the time of your busy day to be here and listen to what I have to say. And thank you to the EF for allowing us the opportunity to speak in this wonderful event. And today I'm going to talk about what is caus approach to multi-party execution and also what is caus approach to the whole crosschain coordination game. I'm Alex Vinas. I'm the head of partners at KOP.

I've been with the team since the beginning since the spin-off so five years ago and before I actually work in in the back then so evil try and now kind of cool because they're coming on chain. So I've broken down the topic the talk into three main topics which is going over why actually crosschain coordination is a hard problem to solve to then go into causab's handling of multi-party execution and then to finish off with what we're actually building to go crosschain in terms of how we coordinate the whole intent crosschain auctions.

Oh, sorry. So, the crosschain wall, right? Uh the crosschain is very hard mainly because of three problems because first the amount of change there are there's been like an explosion of change throughout the past years and also because of the amount of choices that the users have to make to actually make a secure transaction and know what they're actually doing. Then you also have the whole problem of no execution automicity across chain that this is something that kind of breaks everything within the smart contracts because if you live in a single chain world then you have execution automicity but if you go crosschain then you suddenly lose this and lastly you have the whole like chain reorg problem that while in Ethereum hasn't happened in many other L2s this is more of an issue these days so endless choices right if you're a

user you have an abundant of chains to go and also an abundance abundance of ways in which to go to these chains. The problem is that if you're a normal user, you probably don't have the time to do all the research and actually evaluate all the trade-offs of okay, is it better for me to use a native bridge? Is it better for me to use a bridge aggregator? Or is it better for me to actually use Coinbase or Binance to simply breach the assets? Not only that, but from the point of view of the change, you have the different trade-offs that these change provide, like how long do they take to provide me finality? what stage are they on in terms of like the decentralization or most important like what happens if I want to move my if I want to move my funds back to the main chains. So from

the user point of view it's kind of very hard because you know you need to do a lot of research to figure it out and this is the problem that has not been solved and accountab we're kind of like trying to tackle this. Then the second problem we have is that you don't actually have execution automicity right and this is kind of the biggest problems of the crosschain world because if you live in a single chain world then if we look at this for example right and sorry if we look at this for example and we see the simplest kind of settlement contract where you have a sell token and a buy token transaction. The beauty of this and smart contracts what brought the difference kind of like of trfy is that you don't have counterparty risk from

the point of view of the infrastructure right the transaction is atomic I will only release the buy tokens if the cell tokens have been given to me now however the moment you move crosschain or the moment you move multi-chain this atomicity is not guaranteed by the chains themselves but rather by third parties right so we have oracles or different providers like layer zero or warhome who have different messaging systems that actually communicate between chains to actually tell you when to release the cell token. However, even though this reduces a little bit the counterparty risk in terms of crosschains, you're still relying on single point of failure and you basically can end up in a scenario where you're releasing the buy tokens, but then in reality the sell tokens in the

origin chain hasn't actually been moved yet. So this is a problem because then from the point of view of the of the kind of exchange or the swap provider you would have given the users the output token but you haven't withdrawn the sell token. So you end up losing because you haven't kind of charged the tokens that the user wanted to dump and you you have given them actually like more money. So you've made a user happy. And then the other big problem that you have that luckily in Ethereum it doesn't happen but in other kind of layer two or adjacent chains that move around Ethereum it does happen is the whole rear problem right because validators are geographically distributed across the world. They need to figure it out a way into which come to consensions into

consensus and this actually means that temporarily they might see a different version of the chain. And now how does blockchain come into consensus? Well, they define they define what is the fork choice rule which in the case of bitcoin is the chain that has the most amount of proof of work is the chain that is valid and the one that like the transactions you have to trust and in the case of ethereum no in the case of proof of stakes is actually the chain that has the most amount of attestations and that's the chains that valid and the transactions that are going to be count as as finalized.

Now, additionally in proof ofstake chains, you also have the concept of finality which is finality guarantees because you have these checkpoints that basically the whole idea is that every every 64 blocks in Ethereum so every two epochs no we kind of consider the transactions finalized and 100% confirm and this means that those transactions can no longer reorg like a small kind of point is that if kind of the community decided to soft fork or hard fork you can still reorg But from the point of view of the checkpoints like in terms of like if there's a fork choice from now on then that means that those transactions can no longer be reorganized.

Now the other pro the problem that also comes with reors is that even though you know the transaction is confirmed once it lands in a block you still have to wait for finality and this is a problem because the moment we actually have like a fork choice right or a reorg kind of in in Ethereum this means that transactions can be completely different right so if we look at an example where let's say like we have a fork choice and now because whatever kind of issue within one client kind of one I don't know 20% of the network is going on the on the top chain and 80% of the other network that doesn't have that bug on their on their node is actually violated on the on the chain below. Right? So in this case the canonical chain the one

that has the most of the stations is the chain below and the one that has on the top is actually like what there's called like the ankle blocks and the ones that's discarded. Now this is the problem because if you have mutually exclusive transactions right your history is completely different because if the first chain if the what's now the ankle chain you know would have won that means that kind of Bob would have deposited ETH in the bridge and could have not sent ETH to Alice but because the chain that won was the canonical chain the one below actually the first transaction that happened was sent ETH to both so this is kind of problematic because right if you've done like a swap but then there's a reorg and the swap kind of reverts, you might end up in a scenario where

kind of the user has like a um uncheck balance and they have the tokens that they didn't ask or they couldn't even or or you as the exchange kind of withdraw the the tokens themselves. Now I'm going to give an overview of basically causup approach to multi-party coordination and how we kind of upgraded our old model from simple uh frequent batch actions to actually like multi-arty multi-party execution via combinatorial batch auctions. And in case you didn't know and I don't know you haven't heard the famous moo kowab is kind of the inventor of the intents. We were the first project to do intense back when it wasn't cool, when it wasn't a fancy a fancy word or a buzz word. And this was

5 years ago. And the whole idea was basically to build with these three premises where if you combine intents with frequent batch auctions and solvers, you could give the user a much better execution that the co that the common or average kind of deex or dex aggregator that back in the day we had. So first right the main buzz word or the main kind of thing that drives the OEF and all these conferences today is intent. So what is an intent right an intent is simply an expression of I want to trade A for B and I allow you to do it on my behalf. Now based on this the diff the the big difference right is that the user is instead of signing a specific call data or a specific path to

tell the solver or tell the decks hey I want to swap in this specific pools you're rather saying I want to swap these quantities and as long as you respect my limit price I don't mind where you do it and I don't mind how you like distribute or chop my trade now intents combined with frequent batch auctions are very powerful because you can actually like achieve guarantees that other ways you couldn't. So for example like if you're doing intense then you're shifting the whole me exposure that the user has to the solver and then the solver is the one that has to figure out how to do me protection.

On top of that you actually can do coincidence of ones which is actually how the whole name of kowam came to be which is a powerful uh a powerful quality that only kop has which is the idea to match counterparties together instead of matching them with external liquidity pools. So in a sense if someone is selling ETH and another person is buying ETH, why depend on external liquidity when their liquidity can completely overlap. Not only that, but it also actually the fact that you're using batch auction, it allows you to aggregate like multiple transactions in a row and also define a clearing price for the same token pairs that are trading against different uh points in time. And lastly, you delegate the execution of these intents to

solvers who are professional third parties that know way better because their job is to actually optimize these transactions than you as a user. So these solvers are teams that can actually tap into private liquidity, onchain liquidity or even their own uh private inventory to kind of provide the best price for the user. So from the point of view of cow swap when we run an auction it doesn't matter where the liquidity is comes from as long as the user is guaranteed that they get the best price. So we've seen multiple combinations where I don't know 20% of the uh trade will be split with onchain liquidity 20% will be done with a market maker and then maybe 60% is actually done via the coincidence of warrant with other users within the within the batch

itself. So now our old batch auction mechanism our old model the whole idea was okay we have different users from either cowop interface or different interfaces that actually sign their intents which basically creates the orders and then these orders are registered on the order book. Now once the orders are in the order book we actually execute a big batch auctions where solvers have to compete to provide the biggest price improvement the biggest surplus to the users and the solver that provides the biggest amount of total surplus for the users within the auction is the solver that won the right to settle the execution. Now this is a little bit abstract. So maybe with an example it will be it will be way easier right. So if we look at the at the at these four

users and this for SWAS we might have okay Emily wants to swap stake E for USDC then Edith wants to swap USDC for wrap stake E which actually in here is the powerful example of a coincidence of war where the USDC can actually be fully overlap between the users and we don't need external liquidity. Then we have Chiao that wants to swap one inch for cow tokens. And then we also have Renee who wants to swap a steak for a tokens themselves. So the way the solvers will work is that now the auction has begun and they have to place the bits. And for example, we have okay solver A is going to beat on orders one, two and three. So the ST with one, USDC, USDC, rub st and one in and cow.

Solver B is going to beat on orders one to three as well. So they're in direct competition. and then solver B solver C is only going to beat on order four. Now the old results right in the traditional batch auction model will be that okay solver A best is the best bit on the total amount of surplus in the in the batch because he's a specialized solver and he has been able to create a coincidence of one and because coincidence of ones are the ones that create the biggest price improvement instead of tapping into external liquidity he's the one that has created the most amount of total sross for the for the orders in this batch then we have solver B who unfortunately like it their algorithm is not capable of doing coincidence of one. So instead it uses

AMM liquidity to solve orders one and two and three. But the difference between the bit of solver B and solver A is that actually in the solver B created way more surplus on order three than solver one. And then lastly we have solver C that actually did the best bit but it only bit for order four. Now the result of this is that only solver A is going to win. Solver B gets completely ignored because you know the total amount of surplus it's less than the actual solver B and then solver C is well the solution is completely ignored because you have the single winner constraint right the whole idea back then is that we can only have one solver execution executing the result of an

action at a time and of course while this work it had some problems because we actually missed a better execution route Right? In the case that of solver eight, the user for order three was executed with lower surplus that someone else actually found on the on the on chain. It also means that we executed with lower throughput because instead of causup having executed four orders, we only executed three orders. And then something that I guess maybe many people didn't know is the fact that we also had to do a post auction fairness check with what we call the Ethereum best bit offer logic because then we would have to make sure that actually solver a provided the best available bit for the third swap in

a row and in the case that they didn't then they could get penalized and they would earn less rewards. Now in the new model h the way that we do like multi-party execution is through combinatorial actions. So if we have the same system now the big difference that instead of kind of auctioning on the whole thing and solvers having to bid on the entirety of the auctions now actually solvers can only bid on certain parts of the auctions and this means that now solvers can actually specialize on only like certain token pairs or certain specific routes where they know they can really outco compete other solvers.

So if we go back to our example right where we have the four ways to swap and it's the same like ST key to USDC we will have the same bits where solver A is bidding to orders one to three solver B one to three and solver C is only bidding on order four then the results with combinatorial auctions are actually completely different because then solver B is going to win with the best bits on order one and two solver B is going to be is going to win because it has the best bit on only on order three it's the order that actually indiv individually has more surplus and then also solver C is going to win because they have the best bit on order four. So the big difference is that now we have achieved a higher total of surplus within the batch by executing individually these

type of trades instead of like all together in one auction which means that now Kasop has more higher throughput. We can execute way more orders at once than before. And actually like it saves us a lot of time and a lot of kind of engineering hours because we don't have to dedicate the time to the doing these postfactor fairness checks of Ethereum best speed offers from solvers because now the fairness is encoded in the in the mechanism, right? We're going to we're going to allow the solvers to execute that has the most amount of surplus on single orders. There's no kind of collusion like there was before.

Okay, now that we've done kind of how we do on let's say single chain multi-party execution, let's see how we do the crosschain coordination in this uh multi-party execution environment. Right? So uh if we have I guess if we continue with the examples of users are placing intents within the different trading interfaces then the way we actually do crosschain is that we do the swap on the source chain. So basically like the first thing is that we separate the swap and the bridging chain and basically the swap has on the chain on the on the source chains that the users want to trade. We do let's say ETH to USDC or arbitum to ETH in the main chain

and then we actually call what we call swap and bridge. We call bridge aggregators to then bridge the output to the target chain that the user has defined. Now another variant flow that is not live yet but we're working on it is the whole idea of doing bridge and swap and bridge if you want. So why is this important? Because for example right depending on the chain you're you're in the depth of the liquidity and the type of trade that you want to execute might be very bad. Now, however, maybe this is not the case for the same token pairs on Ethereum or on another chain which which with this you can actually do okay let me first bridge my asset to the chain that has like much more like deeper liquidity execute the swap there and then actually like bridge

back the proceeds to the chain that I want the the tokens to be in but because this is not live let's just focus first on the swap and bridge which is what already currently live today so if we go through an example right as I say our current way to do crosschain coordination is basically to split the swap intent with the bridge intent. So if we say I want to sell 100 AR tokens that are living on arbitrum for one web on Ethereum what would happen is that the intent gets registered on the order book and basically sovers compete to sell 100 ARP tokens for one web within arbitrum and as I said the server that provides the most amount of process for the user is the one that actually gets to execute the order. So once this is

happened with something that we call a post hook instead of giving the fonts back to the user we actually send the the funds back to this kind of smart contract that we've called the cow shed which is sort of a flavor of account abstraction because the user doesn't have to trigger anything or do anything with the contract. It's also unique per user account. So the user EOS fully controls the actual the deployment of this cow shed. And then the interesting part is that via ERC 1271 signatures actually the solvers as the one that call the contract and say okay now actually bridge via this mechanism that caused me is the this mechanism this bridge aggregator that Kowat told me is the best way to bridge my assets to this

other chain. And the whole idea of doing it via the contracts is because then the solvers are the one that can actually execute this call because from the point of view of the cowshet, the cowshet will validate okay I have the the the the funds from these users and now I know that I need to transfer them to a specific chain as long as this kind of call data that someone is passing me is what's encoded within my logic. And now this is what the solvers do that once the kind of swap has happened or once the solver has the one one with it actually calls the contract and say I'm I'm bridging these assets on behalf of the other user and then of course once the you know once the bridge has already the bridge aggregator or no there's a winner has been selected the user enjoys

the tokens in the destination chain. Okay, now that we've covered more or less the problems and cows approach to multi-party execution and kind of our current flavor of crosschain, I'm going to explain what we're working on for crosschain auctions and crosschain intense before you know it was this fancy word. Now, one thing to take into consideration is that intent is a very easy thrown word and there are certain limitations. No, because as we saw in the first slide, there are endless choices from the user from the point of view of chains. But not only that, from the point of view of speed, security, or fees, right? How do you really encode the fact that a user says, I don't know, I'm 50% okay with if I'm way faster and

I pay a higher fee, but I'm 20% I don't know, okay, if I do it the other way around, right? It's really hard to encode everything in a in an intent. So, from our point of view, the simpler the intent, the easier like the life of kind of the auction mechanisms that handle intents. So for our crosschain coordination right what are our requirements that we have as mentioned uh because there's so many trade-offs between speed security and and fees we actually want to unify this user choice around one single one single kind of category and this is what this category is what kind of cowop is going to deem trustworthy or kind of like what's going to cons be considered okay to do the trade-offs for the user.

The second one is that we want to actually do true crosschain intents to improve the UX, right? It should be like, okay, sell X on chain A for cell Y on chain B instead of like the current like swap and bridge flow where you actually even if you approve, you have kind of three steps. You have the approval, you have the swap and you have the bridge. But if you have done the approval before, you only have two, right? It will be like the the swap and the bridge. So the user experience needs to improve. It needs to be like a single transaction and a single click like swap A in in chain A for B on on chain B. Then the other important point that no one talks about is that it needs to be capital efficient because we need to reduce the solver barrier to entry,

right? All these other solutions basically are very capital intensive and kind of no one is talking about it because if you're a solver and you want to solve for $100,000 trades across 10 chains that means that you need a $10 million of private inventory. And this is problematic because not a lot of 10 entities have $10 million in their pocket to actually do market make crosschain. And it's even more problematic for the user because that means that there's way less solver competition which leads to getting worse prices. Right? But this is why for us capital efficiency is a very big point because uh one of the aspects that we learned from Nosis protocol B1 which is kind of like the precursor of KOP is that uh the systems need to be

compatible with permissionless liquidity as much as possible because in the event that there is no one kind of market making the ability to tap into liquidity pools like unis swap core force balancer is actually like way beneficial because then you can actually do the execution per se and then lastly it's also in order to do capital efficiency, right? You want to allow coincidence of once, right? Why do a complicated mechanism or involve like a market maker when you have a perfect match between a user that's jumping from one chain and a user that's jumping from another chain. So, this is also like why we're focusing on like improving the capital efficiency in this part.

And I guess this one's for the engineers, right? It needs to be easy to add new chains because if not, it's a pain kind of to do all the work to add a new chains. And one of the things that is important for us is that back in Edcon in 2018, our our CTO did this presentation on how actually multi-dimensional batch auctions help reagregate fragmented liquidity across like the many stable coins because back then we saw okay there's an explosion of assets and you have for example a lot of stable coins that represent the same asset the same underlying asset right the dollar but they're completely fragmented in terms of liquidity And here's where the kind of multi-dimensional batch auctions come to the rescue

because they help to reagregate these markets and kind of create a clearing a fair clearing price across them. But now instead of doing it per tokens, we're actually doing it per change because now you know we have kind of like an asset explosion to the power of change because not only you have USDC, die, USDT or whatever other stable coin, but you also have USDC on ETH, USDC on base, USDC on optimism and so on per network. So this is why we think doubling down on multi-dimensional batch auctions will actually like help reagregate this fragmented um h liquidity across the chain and will actually be beneficial for the for the users.

So now that we have the requirement let's go through the core components which is basically like permission permissionless and composible liquidity. So the ability as I said to tap into the liquidity the liquidity pools in combinations of a ledger that can actually keep track of what's coming in and what's coming out in terms of user balances. Then the whole idea of account obstruction balances right like if we want to I guess like move like it's $100 is it's doesn't matter if I have 50 on base and 50 on ETH it's $100 in total. So the idea is that like with chain abstraction protocol the user has the same balance like across different chains and you can actually like show a single balance which means that now the user can kind of be the liquidity provider across chain within the updates

of the ledger that you might do. And lastly, you need to have combin fair combinatorial auctions because you can't throttle the system where there's only one solver winner all but rather you have multiple winners at once so that you have like a higher level of throughput. So how it works is basically you have a crosschain cow ledger where basically user balances are recorded and then you combine that with the composible liquidity right so for in here for example we will have a user that has balance on ETH and then a user that has a balance of like one ETH and a user that has balance of base of one ETH now if they are going to do a swap in this case like I'm going to explain in the next slide the example is like the user one wants to do wants to sell the ETH

for USDC on base Now the difference is that instead of just relying on a single crosschain cow ledger, we also have this deposit contract where users deposit the phone, but they can also play this resting limit orders that would allow for the crosschain operations to be much more smoother. And then lastly, one big unified auction where you can actually also specify the source and the target chain because right now the way the even the combinatorial auction works is that you have kind of the auction per chain and instead we're going to be moving to like a whole unified auction where if it's only like swaps for single uh like in the case of combinatorial auctions, right? If the winner is only doing source and target of the same chain,

then fantastic like we don't need to do anything crosschain. But in the event that certain orders are coming for crosschain where the source and target are different, we can actually handle handle it in the proper way in the same auction without doing the whole swap and bridge. So let's go through an example to see how what these three pieces that I mentioned work. Because now if we're running the combinatorial batch auction, we could have a world where solvers for example are bidding on orders that are happening only on arbitrum, orders that are happening from Solana to Bitcoin or orders that are happening only on Ethereum or orders that are happening from Ethereum to base. Now the important part of this auction is that the results of it need to consist of two important pieces. once is a bunch of crosschain cow ledger updates so that we actually

keep the track of the balances and then a onechain settlement transaction and I'll explain here why so in our example right we have ah you can see um we have user one who has ETH on mainet and actually wants to get USDC on base and then we have user two who has ETH on base and is one of those users that kind of is activating the account abstraction balances and is placing a resting limit order within the council deposit contract telling them telling us I guess I don't care where my ETH is as long as it's one ETH as long as you respect my balance I don't care if you move across chain now we already have a cow in the sense that we can actually give the ETH from user one to the ETH on user two and

the ETH from user two to one however the problem is that user one actually didn't want they wanted USDC so this is where the onchain settlement transaction component part comes in because then a solver can say Okay. Well, because this user needs USDC instead of ETH, I'm going to go grab the ETH from the deposit contract and I'm going to go on chain to a liquidity pool like unis swap or curve or whatever and I'm actually going to swap and I'm going to swap one E for the whatever the resulting USDC. When I did the slice, the price was higher, but let's say it's 3 3,600. And this the important part is that this solution is actually how you achieve the auto atomicity across across the crosschain swap because you make

basically the conditional right the validators. So in order to cosign the transaction for the validator to kind of verify the solution and cosign the transaction the transaction on chain needs to happen. So in other words, right, if the ordering exception is is observed before, then the validators will will kind of deem this transaction as approved and they will actually push it and kind of the transaction will execute. However, if the execution reverts and you don't have kind of the part of the USDC for web, then the execution will revert and you won't have the the the updates on the ledger. And this is how we kind of see how we do uh automicity across chain because if you combine like ledger

updates with the fact that only one onchain settlement transaction can happen, you can actually guarantee that either kind of the balances move in the correct way and the user's desired outcome has happened or it will simply revert. And this is what we're building so far and I'm running out of time but just in time. So thank you very much for taking the time. Thank you so much, Alex. And thank you so much for showing the exact steps that people need to take if they want to implement the changes that you're making. I hope that this was very informative