DEX Aggregators: Gas Costs, Slippage, and AMMs

Mark:

Today, we're talking about DEX Aggregators with Matt Deible. Matt, thank you for joining us.

Matt Deible:

Absolutely. Thanks for having me.

Mark:

Matt, over a trillion dollars has traded through DEX Aggregators this year alone. DEX's are especially important when things like FTX happens, because people realize more and more that if you don't own the keys to your own crypto, then it's not really your crypto. If you're trusting someone else with custody, then there's an inherent risk there. But if you use a DEX, then you never have to give up custody, which means you don't really have a risk.

This trillion dollars that's trading through DEX Aggregators is likely growing. It's already 10 to 20% of trading volume that goes through centralized exchanges. It's really important that traders understand what DEX Aggregators are, and how they work, and how to actually get the best prices for their trades. Before we dig in, I'd love to understand a bit from you about what makes you such an expert and guide on this topic.

Matt Deible:

I guess I'm somewhat new to crypto in general. I got into it for the first time about two years ago. I come from a AI background. I was interested in studying AI problems. It just so happened that I found AI problems that related to crypto. It was actually related to the many actors within the graph protocol. That was my entrance into crypto.

From there, just starting to learn about all that crypto has to offer and all the new mechanisms. One such mechanism that's particularly interesting is the DEX and the AMM. For about a year and a half I've been intensely studying these AMMs. Basically, the sub problem within these AMMs that I'm studying is how to solve from the trader's perspective the problem of figuring out how to trade through them, because the high level is that there's many different types of AMMs that try to accomplish different things. Liquidity is fragmented across these AMMs. We can get more into the different types of AMMs and why they exist, but it ends up being a very hard problem and a very interesting problem to figure out how to route through these many AMMs. That's what I've spent quite a while now studying, while building the DEX Aggregator Odos.

Mark:

Awesome. Okay, thank you. Why don't we start from the beginning and understand what is a DEX Aggregator and what is the purpose of a DEX Aggregator?

Matt Deible:

Absolutely. Yeah. I mentioned there's lots of pools. Basically, what AMMs do, or most AMMs, what they do is the larger your trade size through them, the worst rate you're going to get. They have this automatic price adjustment mechanism.

Often, what you get is with large enough trades, or even very small trades on low gas networks, it often is worth the gas to send it through multiple DEXs, and to split your order through multiple DEXs and potentially even trade through intermediate tokens. Of course, having a user go to 10 different UIs and execute 10 different trades is not really reasonable at all, and would also use a lot of extra gas because of course every transaction has a given gas overhead.

What DEX Aggregators do is they not only figure out how to optimally route your order through all these DEXs to maximize the returns, they also give you one single transaction that you can just sign and send that will execute all of those swaps for you at once in order to get that best return.

Mark:

Okay. Got it. It's kind of like kayak.com in the travel space. You want to go from A to B. Instead of going to United and Delta and Spirit and Jet Blue, you just go to kayak.com, you put in where you want to go A to B, and then kayak.com shows you all the flights and the routes and even combines multiple airlines sometimes for multi stop trips to get you where you're going the quickest and the fastest.

Matt Deible:

Exactly. Yeah. Yep.

Speaker 1:

Okay, great. I just want to make sure we are also level setting on this concept of slippage and gas. In general, DEXs work differently than centralized exchanges, which have a central limit order book. It's what we traditionally think of as how you match orders instead of price. There's buys and sell. In an AMMs, instead you have a pool of capital and a smart contractors, a piece of code on the blockchain. People put assets in that pool. Let's say it's ETH and USDC, and then traders can use that as trading inventory to switch one for the other at a price determined by this DEX itself, this AMM itself. Obviously the AMM doesn't want to have all its ETH taken and switched to USD or vice versa, because then it wouldn't have inventory to trade anymore.

Basically, it imposes slippage, which is the more you take out of that pool relative to the size of the pool, the worse the price is. That's, it sounds like from what you're saying, is what necessitates taking a big trade and splitting it up over multiple pools or figuring out which pool has the best price and the least slippage at a given time, even though there's this idea of gas, which is a transaction fee for just the processing cost of doing anything on the blockchain that you also have to pay for the more actions you take. Does that supplement correctly?

Matt Deible:

Right. Yeah. There's really, I guess, maybe you could say three things at a high level. There's the current ask price of each DEX. If you were just trading an instantaneous amount, what does the price start at? Then there's how quickly this price adjusts as you trade volume through it. This is one of the most complex parts because each DEX can do this a different way in figuring out how to optimally deal with these mechanisms is the main problem we're solving.

But then there is also, of course, this gas cost. To put it concretely, what we are optimizing as a DEX Aggregator is the value of the output minus the value of the gas. We seek to only add complexity when basically the value of the gas you're paying is less than the additional output that you're getting.

Mark:

Why is this a hard problem? Talk us through how a DEX Aggregator actually architects itself to deal with this problem. Because there's thousands of different pools, and thousands of different assets. What are the... Walk us through the various complexities you have to deal with.

Matt Deible:

Absolutely. Yeah. We can think about maybe increasingly complex solution. We can start off by just thinking of maybe we have a list of DEXs and we just check each one. For a given order, we check each DEX. Whichever one has the best price, we send you there. That would be the simplest Aggregator.

But of course, as we discussed, there's other options. You can split between each one. Now we can think, "Okay, now I will also consider half. Every combination, sending half through each." Maybe you find a different solution there. But really, you have a continuous spectrum. You can send 1.5% through this one, and 98.5% through this one, so that there's a lot of complexity there and you can split between any of these DEXs.

Now we can also think about routing through intermediate tokens. This is triangular arbitrage in some way, where the price from trading through another asset may be better than trading directly to the asset. That's another option that we have. You end up with just a combinatorial explosion of sorts of possibilities that you can end up rounding through. It's searching that space effectively that becomes a DEX Aggregator's problem.

Now, specifically with Odos, one of the things that...

Mark:

Before that, can you give us an example of how you might split hops and go through multiple tokens? Just to make sure everyone understands, walk through a specific trade that might hop through multiple tokens.

Matt Deible:

Okay, sure. Yeah. Let's say you're trying to trade a hundred ETH to USDC. You're trying to liquidate your position. Now, that's a very large trade, obviously, so it's likely not going to be ideal to send that all through one DEX. Let's say first you take 40 ETH and you wrap it with wrapped ETH. You may take 60 ETH and we may send that through, let's say Hashflow. That'll turn into USDT. Now we have 40 WETH and 60 USDT. We can further split that wrapped ETH and send some, let's say 20, over to DIE through Uniswap. We can send 20 directly to USDC like we want through SushiSwap.

Now we have some amount of DIE and some amount of USDT. We can also further split those. I guess I won't continue to complicate this route, but hopefully the concept of splitting and sending through other DEXs, potentially through other tokens as well, is clear. This complexity can get extremely large. Yes.

Mark:

Okay. That sounds like a lot higher than I can count. Okay, got it. These are the problems. It seems like there's another problem too, which is gas is not entirely predictable.

Matt Deible:

Yeah. That's definitely a factor. When you're doing a routing, you have to make some assumption about what the gas will be when you actually execute the transaction. As you just said, that could change, in which case the route that you come up with is not probably optimal for the gas that you're actually going to be charged at the time.

That's definitely a factor. I think, generally, it's still going to be close. You should be paying slightly higher than market gas in general just to get your transaction through and not suffer slippage or any other adverse effects like RFQ, deadline expiration. Generally, you should be bidding a little higher and hopefully that'll get your transaction through, and the changing gas will also be less, but that's definitely a factor as well.

You can solve the gas need problem by guesstimating and then always paying a little bit more. You know that your gas is going to be roughly fixed because you're always paying a little bit more.

Mark:

Right. Yeah, makes sense. Okay. Thank you. I cut you off. You were going to go into how Odos and you handle this complexity.

Matt Deible:

Yeah. Going back to complexity, one of the reasons we built Odos in the first place is that we saw that we had a solution that seemed to be unique and seemed to consider solutions that other Aggregators did not at this point in time.

Hopefully, I can try to explain this in a simple way, but basically what we do is if you look at other Aggregators, they will split between intermediate tokens, but then they'll just start sending it through one token at a time, maybe through multiple DEXs, but through one token. But what Odos considers is splitting between tokens, but then each of those tokens splitting and sending to other tokens as well. You end up with of an interweaving path instead of just a split and then linear paths. That's a much wider space to search. It's much harder to search, but it can also lead to better solutions.

Another DEX Aggregator may say, "Okay, we want to go from LINK to USDC." LINK will split into several... We see several pools. There's a LINKETH pool that has low slippage, and then there's an ETHUSDC pool that has lower slippage. They might route through that. By the way, there might also be another pool, which is USDT, so they're going LINK to USDT and then USDT to USDC.

Mark:

You're saying that actually that's kind of like a first level split. You're saying actually that second hop too, you might want to split between multiple tokens. You get a split at each hop.

Matt Deible:

Right. Yeah.

Mark:

That's actually...

Matt Deible:

Yeah.

Mark:

... even more complicated.

You can see, we have this unique visualization for that as well because we found that the visualization method that existing solutions use, there's an industry standard. That visualization method can't really accommodate this extra complexity. That's also part of the reason we explored this unique visualization. We use a sanky diagram that's able to show this unlimited complexity and splitting and interweaving.

that's an interesting point, which is this is impressive complexity, but if you can't really show the difference and visualize in convenient way, it's hard for people to even conceive of how you're actually better, or if you're better.

Matt Deible:

Exactly, yeah. It's a huge user experience advantage, even if you are getting slightly better rates, to actually be able to visualize that effectively and hopefully intuitively as well. The goal was to get something that you can just look at and have an idea of what's going on and where your assets are flowing without looking at a bunch of numbers.

Mark:

Makes sense. Okay. This makes sense, but it still seems like a pretty big technical problem. I'm sure there's multiple ways to go about it. Do you have a sense for... The DEX Aggregators out there are Odos, 1inch, 0x, OpenOcean. There's a few more.

Do you have a sense of what their view would be on what the optimal way to approach this problem is? How the different... What other approaches you think there are to the problem besides this? Everything's a trade off. Different people are presumably making different trade offs and different priorities.

Matt Deible:

If you're searching a much larger search base, you have to expend a lot more resources. Maybe you can find a better solution, but maybe it's better by 0.001%, and maybe there is no better solution at all. Maybe the best solution doesn't involve a lot of complexity, especially on something like Ethereum Mainnet. There's this idea of diminishing returns. It may not be worth it to go further down that curve. I think we've potentially gone a little further down that curve and I think we have gotten significant gains, but it's definitely... The advantage of a lower complexity search space over maybe a single DEX might be bigger than going from that to a much higher complexity search space, if that makes sense.

Mark:

Makes sense. Okay, got it. Okay. I think we have a good level set now about what a DEX Aggregator is, why they exist, a bit about the different approaches. There's also a lot of different sources of liquidity. There's various types of AMMs, there's RFQs, there's private market makers. All of these have different interfaces and have to be integrated in different ways. Can you talk a bit to us about the differences in aggregating those different modalities of liquidity sources?

Matt Deible:

Right, yeah. This is a very large amount of our work now is finding new DEXs and integrating them. As you said, each one has a custom smart contract interaction. Even when the mechanisms behind the scene are the same, they might still change the smart contracts. That's a additional interaction we have to handle. To maybe give a little bit of motivation here, it turns out, in general, that how good you are at searching this space is quickly becomes less important than your coverage of the space in terms of liquidity.

If you're missing a top DEX, you're just not going to be able to find very good solutions. Even if it's a smaller DEX, but it is very capital efficient, you are still going to be suffering a lot in the solutions you can provide if you aren't able to accumulate a large majority of the liquidity available.

Yeah, that big focus for us is integrating all of these, which has to happen at multiple levels. We have to figure out how to monitor, basically, the state of the pool because that determines the pricing and how we can most effectively route through it. We have to consider how to route through it itself. How does it determine pricing and how can we include that in our algorithm? Finally, the smart contract interactions as you mentioned. How can we actually then include it in this system of smart contracts on chain such that we can interact with it atomically and compose it with all these other AMMs and RFQs and whatnot?

Mark:

How do you feel about private market makers and AMMs in particular? Imagine the Hashflows of the world which are providing private liquidity. They have trading firms who are making quotes and Hashflow basically offers those quotes, verse composable sets of liquidity like Swap or Clipper, which is a hybrid. Both in terms of how you actually incorporate them into a DEX Aggregator, but also how you see the role of those two types of approaches in the market going forward. Which is better?

Matt Deible:

I think they both have very definitive strengths and weaknesses. They both... Yeah. There's a big trade off there. This request for [inaudible 00:20:12] and mechanism in general is extremely powerful to bridge these two worlds. As we mentioned, these DEX is one of the big advantages, especially in the wake of the past weeks, is that you control your assets completely. You execute one transaction, but even within the time of the transaction, you get your assets back. They're never leaving your ownership for an actual amount of time.

Maintaining that mechanism while also accessing centralized liquidity is extremely powerful. That's what this request for mechanism allows this centralized more efficient, potentially, pricing. I will say that's one advantage of RFQs is that you're not constrained by resources of the blockchain. You can either more quickly update your pricing or you can access information that's not accessible on the blockchain. You can use all that to more effectively price the assets. Then you provide this interface back to the blockchain where you basically provide a quote and a signature. We can then compose that with AMMs in our pads in all this complexity, because basically at that point it just becomes data that we can take on chain and execute a function to facilitate the exchange of assets.

Maybe real quickly, just to speak to the trade offs here, the main trade off is basically you get more efficient pricing but you're adding this extra centralized dependency for the pricing. The pricing might not always be available and up, but you are getting more efficient pricing. That's the main trade off I would say.

Mark:

If you're getting more efficient pricing when it's available, and most of the time it's available, how come virtually all volume doesn't go through these RFQs with private market makers with off chain capital, that really isn't a DEX at all?

Matt Deible:

Maybe I should clarify what I mean by better pricing as well. That would be good. I mean better pricing from the perspective of the liquidity provider, which may also mean better pricing for the trader, but maybe not. Most DEXs have this price discovery mechanism, which means the price may trail what market price actually is. A DEX may actually be offering the trader a better price than market.

If that gets sufficiently big enough, maybe it'll be [inaudible 00:22:50] away, but there's usually significantly... Basically, a significant lag time where the better price is not going to be [inaudible 00:22:57] away, but a trader can take advantage of it, if that makes sense. What I mean by better prices for RFQ is that they're better prices for the liquidity provider in that it allows the liquidity provider to manage their risk and to accurately price assets, which may also provide better prices to the trader, but also maybe not.

Mark:

I see. AMMs, because they need trades or arbitrageurs to bring their prices into balance, will sometimes offer worse prices from their perspective that are off market but work to the favor of the trader and work out to a better price for the trader. For that reason, there's always going to be a lot of flow that goes through AMMs because they're actually almost subsidizing the trader. The trader's almost providing a service to the AMM.

Matt Deible:

In some ways, yeah. How bad a price is to the liquidity provider ends up being dependent on future price action, essentially, because it matters where the price goes in the future to decide if that exchange you provided was actually good. But in general, the AMMs are not able to watch the rest of the markets for liquid assets in high fidelity and constantly update their price and react to what the market's doing. A combination, I think, is very, very useful.

Mark:

But it also seems like the AMMs then are getting systematically bad trade flow if they are only getting flow when they're off market, in a way that's probably detrimental to them, then you have these RFQs siphoning off the trade flow that's better and more sustainable for the liquidity providers. It leaves the AMMs in a bit of a bad position.

Matt Deible:

That's an interesting perspective. The other factor here is just how much money is locked. There's a limit to how much trading you can facilitate. There's an upper bound and how much money you've locked. Right now, AMMs have a lot more locked so they can facilitate a lot larger trades. If you have a very large trade, they're probably also going through AMMs right now. Yeah, it's interesting.

Mark:

I see. In other words, AMMs actually might have a lower cost of capital. They can get a lot more capital cheaper because it's I guess, anyone in the world who's potentially being a liquidity provider, whereas these private market makers actually have quite a high cost of capital because it's their own capital. They may be borrowing or levering themselves up and so they have to pay an interest rate and have a cost of capital there. There's all these other things they could potentially be doing with their money, like arbitraging or whatever it is that sophisticated traders and trading firms do. Because they have this high cost of capital, they essentially have a higher cost structure and sometimes aren't as able to give its good rates.

Matt Deible:

That's maybe another trade off that's worth touching on is that the decentralized and permission less and trustless participation within the pricing mechanism is possible within AMMs, but it's not really possible in RFQs. You're trusting that centralized pricing, if you are providing liquidity to an RFQ. That probably will affect over the long term the amount of capital locked in each just because it's a lower barrier to entry to participate in an AMM as far as the trust considerations.

Mark:

Do you see any other trade offs and composability with private market makers? Is there any other drawback?

Matt Deible:

Yeah. The other big one is the deadline. The RFQ trade off is that you are... Well, another trade off is that when you're running an RFQ, you're providing a price but you don't actually know if that price is going to be used or not. You're providing a signature, but it's up to the trader or the aggregator to actually take that signature on chain and execute it. RFQs are left in a state of limbo, so to speak, where they don't actually know what state they are in, what assets they hold because they have outstanding checks that could be cashed, but they don't know when they'll be cashed. One of the ways that you can deal with this, as you're aware, is to put a deadline on it. That at least limits the time that you can have these outstanding checks.

When that time expires, if that was included on chain, then the state of your capital reserves will reflect that. If not, then you can assume that it won't be cashed because now the deadline is passed. From our perspective, deadlines are not great. That's part of the reason we generally recommend a slightly higher than market gas is so that you can get the transaction through before the deadline hits in case of any gas spikes or whatnot. Compared to AMMs where you can, of course, send a transaction a day later, assuming there's no deadlines set there, but generally there's not a required deadline. If the price hasn't moved, then you're going to get... It's still going to go through. Generally, you have some minimum amount out you're willing to accept. That will dictate whether the trade succeeds or not, but there's no hard deadline in terms of time.

Maybe to go along with that, the trade off AMMs have with that is slippage, slippage from the price they originally promised. That's, of course, something that we have to deal with. As one final note, RFQs in some ways still have to deal with that slippage and changing of price, but they take it on to themselves, if that makes sense. Instead of the trader, they have to deal with the, will trades be executed or won't they, in front of... And what order will they be executed? I'm not sure if you agree with that. Maybe you can comment on that.

Mark:

No, I think that makes sense. You have these shifting of costs and liabilities. In an AMM, the risk of price movement in between the kind of, I don't know, "an execution", let's say, is born by the trader and with slippage. In RFQs, it's a firm quote. The risk is born by the private market maker. If anything born by the provider of liquidity is going to have to, that's going to be a cost. It's going to have to work its way into the pricing that can be offered.

Matt Deible:

Exactly. Yeah.

Mark:

If the private market makers are bearing that cost, they're going to have to charge marginally higher prices. That's going to put them in a slight competitive disadvantage. It seems like you have this trade off between surety or predictability of a given trade, and the time it's outstanding, and the price that you'll get on average from these sources.

Matt Deible:

Exactly.

Mark:

That's just a whole nother set of trade offs you have to deal with when you're a trader trying to make a trade.

Matt Deible:

Yep.

Mark:

It's a complex problem.

Matt Deible:

Yeah.

Mark:

Are there any issues with integrating these various sources of liquidity that you feel are too complex or block you from being able to incorporate certain DEXs or certain sources of liquidity because the trade offs they make just don't really fit well into your system?

Matt Deible:

There's definitely some painful ones. I think in general we can make the integration work. It then becomes a question of will they actually be used and how often? If their pricing model isn't super great, then we're just going to continually pass them up and go where the prices are best. There's also some... One thing I will say is that when we're integrating these DEXs, we're trying to do so in as low cost as possible. In many cases, we can essentially execute this large complexity in much less gas than these lower complexity trades cost.

Actually, real quick, I want to mention. This is essentially especially huge on L2s, like Arbitrum and Optimism. On L2s, what we've done is we've sort of compressed, in some manner of the word, the call data that describes this path. What we see is that executing a trade on one DEX ends up being... You can add 10 different swaps to that and you only end up doubling the cost on these L2s because call data ends up being at a huge premium.

If you can manage the amount of call data you're using, your gas costs are way diminished. In general, we're able to execute multiple swaps in much less gas than it would take to execute each swap independently in a separate transaction.

Mark:

Can you explain what call data is?

Matt Deible:

Absolutely. Yeah. That's effectively what, if you look at it at a very high abstract level, that's what we're providing. We're a data provider, just providing call data. Essentially what that data is, is it's signed by whoever wants to execute the swap and that's sent to a node on Ethereum. The Ethereum client interprets that call data and runs it essentially. Part of that call data is defining what function you want to call and then that data is passed to the function and the function can do whatever it wants with it. That data ends up describing to the function essentially what swaps and what trades you want to make.

Mark:

Gas costs are much lower on Layer 2s. In some ways, that makes the gain from splitting between many different sources and hopping through many different tokens much more relevant because the benefits in slippage and pricing are going to outweigh the marginal gas cost required, whereas on Ethereum that might not be the case, especially for a smaller trade.

Matt Deible:

Yeah, exactly. Maybe to put it concretely, I'll say that everything is cheaper on an L2 except for data, because the data still has to go to L1. There's some nuances there in how it's written and maybe you can compress it a little bit, so maybe it is slightly cheaper, but roughly, everything is cheaper except for the...

Mark:

I see. You actually change the way you encode these trades on different chains to accommodate the idiosyncrasies of where transaction costs come from.

Matt Deible:

It makes a big difference to pay attention to the attributes of a given chain.

Mark:

Interesting. Okay. Got it. Quite a complex problem. Do you feel... It seems like there's this dynamic where there's so many optimizations you could make for every liquidity source, and gas in particular. You can always get better by optimizing a little bit more. I would think if you're a DEX Aggregator, you're always going to optimize... It's going to spend your time optimizing where it's going to make the biggest difference to your users. But the risk of that is you get this dynamic where all your optimization effort might end up being focused on Uniswap because today, that's 70 plus percent of the market. What that does is create a systematic competitive advantage for the incumbent because other DEXs, which actually may have better pricing, are going to have inferior optimizations for things like gas. Because of that, not get volume. Because of that, not be prioritized for optimization.

I wonder, A, if you think that dynamic exists or not? And maybe let's just start there.

Matt Deible:

Yeah, absolutely. I think that is definitely valid, in general. I will say that there's... Gas optimization ends up being diminishing returns, like a lot of things. Whenever we integrate a DEX, we make sure we check off the big ticket items, if that makes sense. There's some big things we can do to decrease the gas costs of interaction. Beyond that, there is a lot you can of course do, tinkering around, adding more assembly and whatnot. Maybe you can get it down, but I think that that difference is going to be not too significant to make this. Maybe the effect is still there a little bit, but I think it's not going to be massive.

Mark:

Okay, makes sense. Assembly, can you explain assembly?

Matt Deible:

Right. Absolutely. Yeah. Generally, you write smart contracts, the code that is actually running all these DEXs, and for us, interacting with all these DEXs. You write them in a somewhat high level language, the most popular one being Solidity. Solidity has a compiler that takes this higher level language and turns that into actual bites that can be deployed and basically runs on the network and propagates through the network so that whenever someone wants to transact, they can basically execute using this bite code.

Now the process going from Solidity to this bike code, basically there's a lot going on there. If the compiler is often not doing... The end bike code is not often doing what you want in the most efficient way possible in terms of gas that it's using because you're essentially being charged some amount of gas for every bite there.

You can basically get more efficient contracts so people can... Basically, the end result is people can execute their trades using less gas if you start to write in lower level. If you actually start to write in Yul, which is Solidity's built in way to inline assembly. If you start adding that to contracts and replacing that with the higher level interactions, you're basically closer to the bite code. There's less distance to travel until you get to the bite code and so there's less room for inefficiencies and bloat during that transition.

Mark:

Okay, got it. All right. We have gotten into the weeds here, which I think is really important to understanding actually what's going on. Let's pull out now and consider a question I think this raises for me, which is... The conclusion I take is, is an impossible task for a trader to go directly in many cases and try to get the best price for themselves?

This sounds like a very complex problem and yet DEX Aggregators only have 10 to 20% total volume. Why don't they have 80 plus percent of the volume? Why would users not use a DEX Aggregator?

Matt Deible:

I think a large part of that is just they don't know all that. There's a lot of complexity here and understanding why a DEX Aggregator may provide a better price isn't exactly common knowledge. There is also the fact that this advantage ends up not being massive in some cases. For your everyday trader trading on Ethereum Mainnet, there's not a whole lot of additional benefit to be provided in some cases. If you're trading a couple thousand dollars, just going to Uniswap and executing that transaction, there's a good chance we would just route you through Uniswap.

Mark:

I see.

Matt Deible:

Just because gas cost is so large that you end up having to trade much larger volumes than most people trade for that advantage.

Mark:

Basically, the simpler the trade, the less value a DEX Aggregator will add because there's not that much benefit of splitting it into multiple pools and multiple hops. The larger trade you do, relative to gas expense.

Matt Deible:

Exactly. That's the key. Relative to gas. On something like Polygon, we can almost always do something more complex and provide a better value. On Polygon, I would say you should be using a DEX Aggregator. I think that's mainly just a lack of people knowing.

Mark:

That awareness.

Matt Deible:

Yeah, awareness.

Mark:

Yeah. Well, I guess there's also a benefit to... You've talked about some of the trade offs in making a trade. Some traders... You're optimizing for best price. Some traders might be optimizing for different things. Some people may care more about certainty, and may care less about certainty. That may make them want to use an AMM versus a PMM. Some people may want to pay less gas and take the risk that the transaction fails and be okay with that. Some people may want to... They don't want it to expire. They want the quote to be live for longer. I suppose those are all reasons why you might go specifically to one liquidity source that's built for exactly like you prefer instead of just optimizing for one thing.

Matt Deible:

Yeah, I think perhaps between RFQs and AMMs, there might be room for some legal there, for sure, mainly in that guaranteed quote, verse all of this compossibilty and everything else we talked about with AMMs. Maybe that's a feature we should add, is to only use RFQs, because you can still aggregate RFQs. Yeah.

In general, I think optimizing for output value minus gas value is pretty universal, but you are right. There is some nuance in execution that might cause people to want different things and want to modify that.

Mark:

Yeah, interesting. I keep drawing in my head this analogy back to airlines as we're thinking about how the DEX market will play out. I keep bringing to back to airlines where back in the day, I'm sure people... They just always flew PanAm or something, or Delta.

As that commodified, people use things like Kayak more and more and more. Yet there's definitely people who still fly a certain airline whenever they can. Maybe that's because they're just used to it. Maybe it's because of loyalty programs, but you see a split between direct access and DEX Aggregators even in the airline space, even in what seems like a very commodified product. That's probably how the DEX space will play out as well with DEX Aggregators and individual DEXs.

Matt Deible:

Yeah, I think there is always going to be people who just go to Uniswap. Uniswap has the biggest name recognition by far, I would say. I think over time, the percent of trades going through DEX Aggregators will grow. I don't think it will ever hit a hundred, of course, or get super close to 100, but I think it will grow. Yeah.

Mark:

Makes sense. I think you're probably right. One last question. Do you think Uniswap is sustainable? Do you think those economics even work?

Matt Deible:

From the liquidity provider's perspective?

Mark:

Well, really either, because if it doesn't work from liquidity providers perspective, then it can't sustainably work from the trader's perspective. A system can't work unless everyone is better off using it. All the participants are better off, otherwise it collapses. I'm curious what you think the future of Uniswap is.

Matt Deible:

This is something I would actually like to study a bit more. I don't think there's... As far as I know, no one's really tried to study the returns of different models, including Uniswap and how these different AMM designs, everyone... There's a lot of reasoning and thought that goes into making these AMM designs. There's less so that goes into comparing them, I guess, and comparing their payoffs and what the actual yield you're getting is, of course. There's always two components. There's a loss you might actually face as well as the revenue.

Studying how these different mechanisms, what yield they actually begin to create, and are those yields actually even positive, is something that I think needs more studying. There's a reason why it hasn't been studied too much so far. It's because that number ends up relying on future price action, which of course is hard to predict. If you can predict future price action, there's lots of things you can do with that. That's effectively what concretely evaluating the value of providing liquidity to these pools ends up simplifying down to.

I'm actually not sure what the yields of these pools are right now. I'm not sure a lot of people are. Something like Stablecoin pools are the only thing I can say are... Unless one of the Stablecoins de pegs, of course, those will have positive yield because they're so static around that one-to-one exchange rate price.

But other things, yeah, it's hard to say. It's hard to make any predictions of where that'll go without having more concrete numbers on how these pools actually perform as yield bearing assets, essentially, these liquidity provider positions.

Mark:

Makes sense. Well, a conversation for another day and another podcast. Matt, how can people learn more about you, follow you, and use Odos?

Matt Deible:

Absolutely. Yeah. Twitter, Matt Deible. Odos also has a Twitter, Odos Protocol. I would encourage everyone to follow both of those. Check out Odos at odos.xyz.

Mark:

Awesome. It's Deible, D-E-I-B-L-E, correct?

Matt Deible:

Correct, yes.

Mark:

Great. Thank you so much for joining us for the hard work you are doing at odos to deliver the best prices for traders and for sharing your knowledge with us today. Really appreciate it.

Matt Deible:

Absolutely. Thanks for having me.

‍