Making DeFi Truly Cross-Chain by Anna George - Devconnect

[music] Hello. Hello. Cool. Thank you everybody for coming. Um I'm going to present a way of how we think we can design crosschain markets more efficiently.

And for this we will first um briefly talk about multi-chain again. Why has crosschain become so important? Everybody is talking about it. Why is it important that we solve this? Then we will talk about what actually makes crosschain so hard to solve.

Then we will briefly dive into existing solutions of other dexes and their crosschain solution and talk briefly about the trade-offs. And lastly, we will dive deeper into a new design proposal of how we believe we can actually make crosschain intents more efficient. All right, let's start. Why crosschain? I assume most of you have probably been in the space for a while and have seen a lot of dozens, maybe even hundreds new chains being developed.

All of them with different use cases in mind and different advantages that they bring to the market. Um, probably many of those will not be around anymore in a few years from now, but some of them definitely will. And one thing has become very clear that there's not only going to be one DeFi chain that will dominate all of DeFi, but there's going to be a multitude of different networks that will all serve their own use cases. And we need to make sure that we can serve these use cases and that we provide a good user experience by tapping into these chains. The problem is today there is not a good use case situation, right?

Like users they try to bridge over to different networks. They need to do research into what are existing bridging providers, what are the security trade-offs of these. They need to handle different gas tokens in their wallets. And then they also need to always look for what is the best liquidity route that they can find. So if we want DeFi to truly succeed, if we truly want the next billion users to come into DeFi, Trefy to use DeFi, we need to solve this complexity and provide an abstraction layer that allows users to have a very smooth interaction across all different networks.

We have been able to solve this on a single chain in the past, right? We had similar issues on a single chain in the past. Terrible UX, lots of fragmented liquidity and then different aggregators have been built and also intense really revolutionized the way of how we interact with blockchain. So on a single network this has been solved but on crosschain we are basically back in the past we still provide very bad user experience. The question is why?

Why is it so much harder to solve this in a crosschain environment than it has been to solve this on a single chain. The reason is that in a single chain you have automicity. This gets lost in a crosschain environment. What does atomicity mean? This essentially means that if you do a transaction either the entire transaction gets executed or none of it.

But you cannot struggle and have like only component of a transaction being executed or take away user funds but not return the the buy token to the user. That cannot happen in a single chain because you have this atomicity. But in a crosschain environment this atomicity breaks. So now what could happen is that you have a user who for example on arbitrum wants to sell their token and wants to buy tokens from Ethereum mainet and since you don't have atomicity it's theoretically possible that you take the user funds away on arbitrum but you never give them their funds on Ethereum and that's obviously a bad situation that needs to be avoided and so what you need now is because you don't have shared state between different blockchains that would solve this problem. You need to come up with a messaging layer in between as a variety of different solutions.

Light clients, native bridges, even TEES. The problem is you will still have to rely on a third product protocol. Um and of course also between different layer one solutions. So there it's much less uh product infrastructure currently available that does the communication that handles the communication between those two networks. Lastly, another big issue is that you have different finality periods.

So just because the transaction gets included in a block doesn't mean that it will ultimately be included on the blockchain because you have reorgs and so you need to theoretically you cannot just see okay the transaction has been included on Ethereum now it's safe I can now deposit tokens to the user on arbitum no because you need to wait until Ethereum has reached finality and that takes time so theoretically for full finality on Ethereum, you need to wait for two epochs, which is approximately around 15 minutes. Um, and for other chains, it can be longer. For other chains, it can be shorter. For Bitcoin, theoretically, it never really reaches finality, even though most people would probably argue a couple of blocks is sufficient. And yeah to so to sum it up why interacting across different networks is so difficult is because you don't have atomicity which means that theoretically there is a risk that you double spend user funds or that you never return funds to users.

Um you solve this with help of some messaging layer in between that you need to trust. And then lastly, you have to deal with these delayed time periods until blockchain really has hit finality or find a way around it to provide good user experience because of course no user wants to actually wait 15 minutes to get their their token balance up updated. All right. Unfortunately, I would love to focus more on this section. Um, unfortunately, we don't have enough time for this.

This would be an entire talk in itself. But there are already a bunch of different solutions live and specifically here I'm focusing on dexes and how dexes um handle crosschain solutions. Um again unfortunately no time to go into depth here but basically if we all of these different solutions that were taking a bunch of different trade-offs in order to handle the situations the issues that we have just discussed and there is one common denominator between these which is that all of them are not very capital efficient. The reason is if I as a user want to do a trade let's say again between Ethereum and base then I if they need to have a counterparty that is executing this transaction the trade for them on the destination chain so if I want the user experience to be fast there is no time to wait for finality there's no time to do proper bridging between the two blockchains so what happens is that usually a party who executes the trade on behalf of the user on the destination chain is leveraging their own capital in order to get the trade done and then later it's going to be repaid from the user's deposit. In some of the solutions it happens faster and some of the solutions it can actually take up to couple of hours until the solvers are being repaid.

But the core point here is and I think it's easier to highlight this in numbers. If you're a solver and you want to only provide and support solutions for 10 different tokens across 10 different networks and for a trade size of up to 100,000, then you have to already lock up capital of $10 million. And that's problematic because there's very few solvers, very few market makers that just have $10 million laying around that they can use to engage in this. And this is the c one of the core issues that we will be focusing on on how we can solve this. All right.

Yeah. Let's go to the main session or section here. Um looking at a proposal of how we believe we can solve intense on a crosschain environment by significantly reducing capital requirements. For this I wanted to first review again what is actually the requirements that our solution should be able to fulfill. One is that we want of course a connection between all networks not just between layer 2s but between also all types of layer ones.

We want connection between Ethereum, Solana, Tron, whatever, Binance everything. Then we want to be able since we're talking about costchain swap intents, we want to be able to also include a proper swap. Some of the solutions from the previous slide actually don't even include a swap. They merely only focus on bridging, but we want a user to be able to do a transaction that changes the the token in their wallet. Really important is also that we only want to have one single interaction.

So you don't want a user to have to sign multiple transactions and you don't want a user to have to sign a transaction, wait until something has happened, then come back and then sign another transaction. We want to be able to tap into onchain liquidity. So to make sure that the swap can actually tap into an existing onchain liquidity pool such as unis swap balancer or whatever. We want the outcome to be atomic. So we want to very make sure that the user either the whole user interaction happens or nothing happens.

So we want to avoid that the user ends up with a token in between. Let's say they want to have um that they have ease on Ethereum and they want to have USDC on on Solana then we want to make sure that they don't end up having ease on Solana but they want either they keep the balance that they originally had or they actually receive exactly the token that they wanted to receive. And then we want to make sure that the user actually has strong competition. This is one of the big issues if you have too high capital requirements because then you have barely anybody who can participate in the competition and the user will suffer from this because they will receive a worse price at the end if there's no strong competition in finding the best route for you. And of course we also want the solution to be somewhat timesensitive.

Again, users don't want to wait around forever. And last but not least, the point of being capital efficient to ensure that you have strong competition and that you actually also can tap into a variety of different tokens and trade sizes. All right. So, we think we can fix this. We think we can fulfill all these requirements with one single vision which is to create one single auction that unifies liquidity and orders across all different networks.

So essentially whether a user just wants to do a same chain trade or whether users want to do crosschain transactions they should all be united in one single order book for which there is one unified auction that is running and yeah this auction should run frequently again for for time reasons of course we want it to run fairly often and we want to run it with a strong server competition that guarantees that users outcomes get maximized that they get best possible liquidity. The challenge of this idea is that of course if you have um a solver competition then you need to realize that there's not one single solver that is deployed across all different networks and that is tapping into all existing onchain liquidity. So if you had an auction where only one solver gets to win then the majority of the transactions in the order book would either never be executed or it would take a very long time for them to get executed. So to solve this, what we now need is a combinatorial auction, which means that multiple solvers cannot only submit multiple solutions in parallel, but also get to win and execute onchain multiple solutions in parallel. The importance here is that of course the subset of transactions that they execute cannot be overlapping with each other.

So they need to be mutually exclusive. And then you have multiple servers. They can all look at a different subset of the order book provide solutions and whoever finds the best route for an for a subset of the order book gets to execute it. And these are multiple servers in parallel multiple executions in parallel that can happen. This is actually component that is already live today.

There's one word I wanted to highlight here which is that we're not just talking about combinatory auctions but talking about combinatorial batch auctions. A very small word but a word that can be extremely powerful. The reason is or first of all what what do we mean by batching? By batching we mean that we can match different orders peer-to-peer together. So if you have a variety of orders in an order book, we can actually match them against each other.

Very simple example here would be that somebody wants to sell one Ethereum E and buy soil on Solana and someone else wants to sell Solana and buy E on Ethereum. So now you can match these two trades together and theoretically you don't even have to touch any onchain liquidity. The reality though is that in most cases you probably will have to have at least one on onchain interaction because the likelihood that the volumes of both transaction is exactly equal is very low. Um but the majority of this trade you could already settle by matching these two user orders together and then you would have one additional onchain transaction for settling the excess amount. All right.

Why I said this is very powerful and it is especially in the crosschain environment because now if you look at data about 80% of all crosschain volume is touching five tokens. So now that gives us a huge opportunity to to basically have all these different uh transactions that deal with the same tokens to match them against each other and then have significantly less capital requirements to just focus on the leftover traits that are not covered by these 80% and ensure that we also have a smooth experience for those. So this is already what I like this is already really powerful how crosschain happens today and the overlap of tokens in it. But we can actually bootstrap this even further. So there is a lot of talks about different projects currently that talk about crosschain abstraction.

Basically saying users they don't want to know where they hold their tokens. They just want to know okay I have 10,000 USDC. I don't care that 5,000 of the USDC are on Binance and the other 5,000 are on Ethereum. So, there's of course users who do care because theoretically this chain abstraction also means risk abstraction because just by the token being deployed on a different underlying network means also that you have slightly different security assumptions. But most users actually don't care.

And there's specifically protocols like one balancer um who are focused exactly on this on abstracting this complexity away and providing one single user interface that just shows hey this is your total balance of 10,000 USDC you don't care where the where the USDC lays and this gives us a huge opportunity because now if the user does not care on which network their USDC lays that means they can have standing limit orders where they say you can always exchange my USDC on on base against my USDC on e Ethereum or against my USDC on Binance because in the end I don't care on which networks I hold it and as long as I get a little bit of surplus for you doing this balance change for me I'm happy and yeah this is a huge market to tap into and a part of this market we already see live today so on cow web Today there's already a huge amount of trading volume stamming fund users who want to simply exchange one USD packed stable coin for another one in exchange for a little bit of surplus. So already today there's a bunch of users having standing limit order saying here trade my USDC for USDT for D for whichever for whichever other USD packed stable coin as long as I make a little bit of income off it over time. And this is of course a huge potential now to tap into this liquidity and additionally use it for our crosschain solution. All right, let's uh go back to how exactly the design mechanism works. So you have the one auction and then there's of course an additional component you need which is this balance sheet.

You need to keep track of which orders that participate in this auction have what type of tokens in their wallet. And for this we are introducing a ledger. Basically think of it as an account accounting layer that keeps track of the user balances and how it would work is that a user depart deposits into this ledger um which actually also can be abstracted away. It would be like a smooth joint transaction of the deposit plus the just the the trade the the trade intent that it would express in one single transaction and then the balance gets reflected in the ledger once and here's an important point once finality is reached again here you would say oh but then you have the problem again of this system taking too long if you have to wait for finality so this is actually something that has already been solved not by us but by circles CCTP v2 introduced a very clever solution for this. They're using an insurance fund that says okay we we do realize that real finality on Ethereum takes around 15 minutes but de facto if you look at the last few years that never happens.

So actually we are already happy with a much shorter finality period. let's say three blocks uh for small amounts and then of course the larger the volume is that a user wants to settle the longer this insurance fund would probably want to wait until they accept the the deposit on the ledger and say okay even though the chain has not yet reached full finality we are already fine with updating the balance sheet the the ledger and and say it's final and yeah and then lastly of course if a user ever wants to with like wants to receive the token on the destination chain. Again, we don't want to have a separate transaction where they have to now say, okay, I want to withdraw my my new balance on on Solana or wherever. But of course, it would also be automatized with half of a post hook. Okay, this is yeah the basically all the infrastructure that you need.

And then let's look concretely as at a crosschain settlement. It has two steps or like two transactions that it involves. [snorts] One ingredient that it involves is an update to this balance sheet to the ledger just saying okay after I do this transaction this is the new balance sheet. This is how much funds each of the users now holds. And the the second ingredient is that you need to have or that you can have this onchain settlement transaction where you also use the balance and uh use that to to um interact with an onchain liquidity pool like unis swap uh like like balancer or curve or whatever to to do one onchain transaction and then what happens is the solver submits this proposed solution solution.

They say this is the balance update. This is the onchain transaction that I want to do. The validators review it. The validators of this ledger review it. And um if everything checks out, they co-sign the transaction.

Then the solver has a given period of time during which he can execute the train on chain. If it happens then the solvers the the the the validators will update the the balance sheet accordingly and say okay now the user has this new um basically in this case the 3,600 USDC uh deposited on Ethereum and yeah and then that this is the positive case scenario and um in the negative case scenario if for whatever reason the onchain transaction fails which can always happened, right? Maybe someone removed the liquidity from the unis swap pool. Maybe the unis swap pool's price point was outdated and that and in case this settlement reverts, then very easily also just the ledger uh balance sheet is updated accordingly and reflects again the the balance of the users before the failed transaction. Okay.

And now we actually have a really cool use case um which is the one where the previous one was just one single normal user interaction. I want to do a crosschain swap. The more much more interesting use case now is that you actually have these standing limit orders in the order book that you now can leverage for additional onchain liquidity. And in this case you have um a user who has a standing limit order. This is user two who has one ease deposited on base and says okay I'm happy to I don't care if my ease is on base if it's on arbitrome if it's on salana or whatever I just have this one ease and [snorts] uh it's available for solvers to tap into this and then there's a user who actually wants to do a crosschain trade specifically they now deposit their ease into arbitum it gets updated in the ledger and now reflects user one has one ease on arbitum user two has one ease on base and now in the next step the solver knows okay this user who has one is on arbitum they want to receive USDC they want to receive USDC on base so now let's say the server has zero capital themselves what they can do still they see okay there is actually capital available somebody has one e on base let me leverage this and they will submit a solution to the ledger which includes basically the proposal that now user two changes their ease um balance from from base to arbitum and user one who wants to do the trade there is now getting this user 2's ease on base in order to use that funds to execute it against onchain liquidity in this case a unis swap pool to receive the USDC that they want so it's a very elegant way to use pre-existing capital without actually having to do any bridging and just updating the balance sheet here.

And yeah, the the server provides the solution. The validator set cosigns the transaction. The solver this way gets to execute the trade on chain. It happens. The balance sheet gets updated.

This is the happy pass. In the unhappy pass, as mentioned before, if the transaction reverts, then the balance sheet is just reverted as well. User one again has this be east balance on arbitum, user two has their east balance on base. Simple as that. And yeah, um while in the past we have been trying to like solve DeFi a lot in silos, we are really now trying to break these borders across different networks.

And this is exactly what our solution here is trying to achieve by having one platform with one auction and one unified user experience across all existing networks. That's it. Thank Moo.

Thank you so much. What awesome. Thank Moo is incredible. I love that's an awesome slide. Um so we have again a bunch of questions from the audience.

Um I mean that that was incredible. I think one thing that when I think of interoperability and crosschain, it's like today's experience of going from one chain to another is like if you were using Google Chrome and every time you were going from one website like Facebook to another website like let's say LinkedIn, you had to change your Wi-Fi router and it's like this arduous process, right? You got to change the RPC, all this sort of stuff. and having it actually feel like one chain and having crosschain liquidity and coordination be solved is in like will basically make DeFi feel like the internet today itself. Um so first question that we have is do we need to solve the multi-chain problem on an app layer or a chain layer?

That's a good question. I think I would say on both like of course there needs to be infrastructure how different networks coordinate better with each other but I think it has its limits like you have layer twos that are of course working on interoperability with their base network but I think it's unrealistic that networks like Sana EMR etc will come up with their own perfect solution how they can be more interoperable. So I think there will always be a component that has to be also solved on the app layer. Awesome. Um, how do you think about trust when it comes to this?

Yeah, for us it's very clear that we I mean the reason that we are on blockchain, right, is that we don't want to have to rely on trust. So whatever solution we build, we want to build it fully decentralized and in a way that we can minimize trust as much as possible. So this is why we we like we haven't published any concrete details yet about our ledger solution. But of course the idea is to work with a very secure validator set in order to remove any trust assumptions for this that that's for us it's always been a core I think if you know the background history of cow swap um the the very first protocol we actually ever worked on was by by external parties always um categorized as the most decentralized protocol out there. It had the disadvantage that if you if you're just working on it heads down fully working on decentralization, it takes a very long time to go public with it and you might miss user needs.

This is what happened to us back then. So when we designed cow protocol, we try to go a little bit more loose on like not being fully decentralized from the get-go, but it is our vision. This is 100% where we headed. We want 100% decentralization.

Awesome. Yeah. Yeah, and you have users today that you listen to, that you get feedback from, and I think the way you've structured it has been awesome to see. Um, how do you protect limit orders on risky asset pairs from toxic overflow?

I mean, the the good thing about limit orders on cowop is right that you basically um it's the only limit orders that can generate surplus. So I mean with limit orders per default you're protected in the sense that at least with out of market oh I guess maybe this is not asking about out of market limit orders but in market limit orders

um it just says put limit orders I imagine in market

okay if I if I answer your question find me later and talk to me about it I might misunderstand it but like the the cool thing about ko limit orders is actually that obviously if it's out of market the only way that they get filled is anyway if the onchain price point is hit but the cool thing on kop is that actually since we have the strong solver competition in many cases users get more like a better price than the limit order which is the only protocol that actually does that. So a few weeks back when the when we had this flash market crash and a lot of protocols a lot of sex centralized exchanges actually didn't work like the limit order feature just didn't work the orders didn't get executed swap still worked and a lot of users had very positive feedback because they actually received better price points than what they had been asking for in the limit order. Yeah, I mean like DeFi just works. It's incredible. Um,

yeah, I guess in terms of what you would want the protocol to do to better assist you, uh, is there any requests that you have or something that you wish you could see on the protocol layer?

Um, you mean that we would want from base protocols in order that would help us? Um in in general I think we have been very advoc strong advocates on solving ME and we think that it makes sense to solve it on the application layer as much as possible. I still think that's also something where the base layer could probably additionally help. Um yeah but uh but in the end I think we we always try to maxim like optimize for users as much as possible as what we can do from the application layer and on the other hand I think also base layer it's good that they focus as much as possible on really like just core issues to ensure that they keep being decentralized. I think it's once you start giving more requirements to the base protocol, it's a slippery slope of them adding too many policies that might harm decentralization.

This is something what we have actually seen when Ethereum implemented um proof of stake as a component of like decentralizing the validator etc etc that actually led to a huge decentralization from block builders right and that was like a response to trying to solve the me problem. So it ultimately to some extent made it worse. So I would say I would keep the the base layer as much as simple as possible and try to focus to solve a lot of the UX issues on on the application layer.