Valve: Routing Building Blocks for Uniswap - Prabhaav Bhardwaj

So, Balancer Finance, we got a grant from Uniswap to essentially identify inefficient Uniswap routes. So, as everyone on this forum knows, Uniswap has a pool where two assets are traded, and the price is determined, essentially is determined, essentially , after the trade, when arbitrageurs come in and either bring the price back to the proper level, or, well, actually, yes. What is happening with Uniswap right now in terms of UX and interface is hard-coding routes through certain tokens. So, the tokens are mentioned here below. ETH, USDC, Maker, COMP.

There are several reasons for this: first, these are the tokens with the most liquidity, for which people can add pairs. And they are also the most well-known tokens. Now, what happens with the interface: when a trader comes to exchange token A for token B, Uniswap V2—and I'll just note that this only applies to V2, not Uniswap V3. So, in Uniswap V2, even if there is a better optimal route, UX will route the transaction through six hub the transaction through six hub tokens. And because of this, pairs that are not part of these hub part of these hub tokens end up being misvalued .

Then these " these " vampire" bots appear, which come in and arbitrage the price back to reality. And the liquidity providers (LPs) of these pools with mispriced tokens suffer inconsistent losses. Another problem with Uniswap is routing, as they focus on giving you the lowest gas fees. This is great up to a certain threshold. Suppose if your transactions are less than 500 or 1000, take any number, a small number number, a small number .

This is normal because the lowest gas fees are better for this . But when you want to make a much larger deal, say in this example for 10,000 Badger to GRT, you pay for it with significant slippage. So, the price impact is about 14% because Uniswap only uses one route. They don't do any order breakdown or routing like 1inch does. So you can see in this example that you get about 140,000 GRT for Badger, but 1inch gives you about 160,000.

They optimized for profitability, not gas, and I'll talk about that in more detail in the next few slides, but you can see that they can, essentially, 1inch can, essentially, 1inch is a DEX aggregator, so they have the ability to use multiple protocols in this case to provide you with the maximum revenue. Here's another chart that summarizes what I was talking about regarding gas fees. So Uniswap, regardless of the prices, regardless of the size of the deal, will always have the lowest gas fees because they usually use one route, in one or two passes, whereas DEX aggregators, as you can see in the chart, as the order size increases, they start to split it up, use multiple protocols, and the gas fees, of course, become significantly higher. But that doesn't matter when you have a large enough order that the profit more than covers the gas commission covers the gas commission . And we see this in the types of transactions that take place on Uniswap and 1inch.

So, on Uniswap, the median deal size is around 1,000, and the peak was around 2,000 at the end of last year. But there are many more big deals happening at 1inch. And this is a big problem for Uniswap, because all these fees are going to other protocols, even though they should have stayed in Uniswap. Therefore, the solution we are working on is to algorithmically eliminate routing inefficiencies. Instead of hard-coding six hub tokens and hoping that it solves 80% of the problem while ignoring the remaining 20% ​​of ignoring the remaining 20% ​​of inefficiencies, we propose a solution where we traverse the Uniswap graph for all routes, regardless of hub tokens, and give you multiple options to choose from.

Our current grant that we are currently working on is to define multiple routes from token A to token B, independent of the six hub tokens. In the future, we want to split transactions between multiple pools. This is exactly what 1inch does, but instead of using multiple protocols like 1inch, we can do it within Uniswap thanks to the availability of multiple routes. Even more interesting ideas are testing and modeling these routes using accurate real-time gas and liquidity data. We have now built our system using a graph-based backend.

And also covering protocol versions. A lot of liquidity is going into V3. However, a significant amount of liquidity still remains in V2. And with talk of Uniswap rolling out to a second tier, liquidity will become even more fragmented more fragmented . Therefore, giving users a holistic view of where their trades will yield maximum profit is important.

Of course, we can implement more interesting order types, like limit, range orders, monthly buys, etc., which the current UI simply doesn't support. So, here's a quick example of our tool. So, similar to the Badger to GRT deal that I talked about, all of these routes are Uniswap routes that we have combined. For a fairly small transaction of 100 Badger, of course, the Uniswap route makes the most sense.

But as you enter larger and larger trades, simply splitting the order into two or three routes will significantly reduce slippage, which, as I mentioned, more than offsets the gas costs. And, more importantly, all LP fees remain on Uniswap and do not move to other competing protocols. Regarding the idea of fragmented liquidity that I mentioned, I just wanted to add more data to that. So, if you look at Uniswap V2 and V3 now, there are a lot of trading pairs that are repeated in both V2 and V3, and as you can see, the liquidity is fragmented. So, simply by creating a kind of DEX- kind of DEX- aggregator of Uniswap routes, you can get much better profits from large trades, and traders who want to make such trades will not have to go to 1inch or another DEX- or another DEX- aggregator.

They can make both small and large transactions entirely on Uniswap. Some ideas we have also explored are deals with MEV protection. With the advent of flashbots, we are all familiar with what is happening with MEV, and if you go to explore.flashbots, you will see that Uniswap V2 is the largest source of MEV. There are many different reasons for this.

Several of them, like the previously mentioned incorrect pricing of pools not included in hub token routes, are a good reason. And also using flashbots to hide their transactions would greatly improve protection against MEV for Uniswap users. Some future possibilities we are exploring. One that makes a lot of sense is a unified professional interface for Uniswap traders. Similar to what Coinbase and Coinbase Pro have for professional traders, we are thinking about creating a single UX for Uniswap where you can see liquidity across multiple tier 2 providers like Arbitrum and Optimism.

You can view it on multiple protocols, whether it's V2 or V3. And also the advanced features I mentioned earlier. And for this there is a great parallel with Quinta. Quinta parallel with Quinta. Quinta is a team that split off from Synthetix that created a better interface with advanced features that the Synthetix exchange simply provided Synthetix exchange simply provided , and they use Synthetix on the backend.

Some other features we've been looking at, and these are mostly for future grants. Of course, there is the deal generator I just talked about, testing and simulation of deals with MEV protection, a unified interface, up-to-date prices and real-time data. This will be absolutely, absolutely critical when you need to make trading decisions based on the data we provide. And of course, constraint editors if you want to set a specific slippage specific slippage , gas thresholds, or number of transitions, protocols, levels. Um, since we're solving a problem for traders, it makes sense to look at the other side—the other side—the supply side, with LP providers.

Some of these ideas were discussed in the Uniswap Discord, these are features that the community is looking for, such as automatic position management position management , algorithmic; I know , algorithmic; I know that Sommelier does part of this. Um, there are also interesting points, like providing only one part of the swap. So let's say you have BAL and MKR, and you only have BAL in your wallet, and you want to provide only that, and you have to wait for the other party to provide MKR. So some of the ideas here are similar to what CowSwap does with random swaps, essentially finding the other side of the liquidity for you so you can add it to the pool. And of course, the unified interface keeps getting mentioned over and over again, whether it's LPs or traders; Having an interface that allows you to see all liquidity across protocols and levels is absolutely critical.

Um, and also opportunities to invest your money. So if you're an LP today, you know, it was on Twitter, on Discord, that providing liquidity in the current Uniswap interface is confusing: where do I set my ticks, etc.? And also, which pool should I invest my money in? Where will I get the best return on my money? So these are some of the problems that we can potentially solve in the future.

Um, that's all I had for the presentation. I can quickly walk through our working demo. Um, so here we have a basic interface for an input and output token. Um, so let's say I want to switch from Aave to Balancer. Um, I can enter a certain number of tokens that I exchange, increase the number of transitions, and then say that this is the maximum level of influence that I am interested in.

So when I do that, it will return a bunch of routes. So, it is clear that for a small transaction, Uniswap will be the option that will provide the most optimal exchange. And as you can see, this animated line indicates that this is exactly the deal we recommend. Now, as you're trying to move into bigger deals, like I said about Badger, let me quickly demonstrate this. So, let's move from Badger to GRT.

I'll start with a hundred badgers, and that will show you the different routes that are possible. Again , these three, or maybe even four, routes have fairly similar profitability, but if you split that into two or three paths, you'll get a much higher income relative to the commission costs. Now, if I increase this to 1000, you'll notice that the Uniswap route starts to get a lot worse because they're just choosing hub tokens. But yeah, this is kind of a short demo of what we're working on. I'll ask AC to just insert a link to the article we wrote.

It covers the ideas we had, how we're thinking about it, and there's a lot more technical detail about how we modeled our data, as well as what we're planning for caching and scaling for real- time. And of course, we recall some of the information I went through, along with potential ideas for the future. We would love to hear community feedback on this. If you think some of these ideas are great, there may may be ideas we haven't considered that interest you. I would really like to hear your thoughts on this.

That's practically all I wanted to present. Happy to answer any questions. Thank you. It was a great performance and a really interesting idea. We have a question from the chat: what happens if someone arbitrages one side of a liquidity pool (LP) through another decentralized exchange (DEX) at the moment exchange (DEX) at the moment you execute this trade?

That's a good question. We...Is this from another text? Is this... I think so.

I'll ask him to clarify that when they hear from us in a few seconds, but the assumption is that it is . Yes, I'm not sure. We'll have to think about this in more detail. From our perspective, at least initially, we were only thinking about how to provide better profitability for users. Just do the bare minimum, because people shouldn't have to go to a DEX go to a DEX aggregator when there are multiple ways to exchange token A for token B on Uniswap.

Of course, there are edge cases that the person asked about, and we need to consider them. I would be happy to discuss this separately and talk in more detail. I think AC is also in the chat, so of course he can answer this. And we received clarification that yes, in this context we are talking about another DEX. So, that makes sense.

You showed a really interesting demo. I guess my question is , what are the remaining open issues that you haven't addressed, where are the various trade-offs, and what does that mean for the roadmap so that others can freely test it? So, as I mentioned on the previous slide, the first part of our grant was simply to identify them. So what we plan to do is this: since we already have a working demo, we need to have more up-to-date liquidity and pricing data. We update this about once a day about once a day .

We want to get closer to updating every 15 seconds or every few minutes. Ultimately, we aim to connect directly to JSON RPC and receive data in real time. So you will be able to make these trades and compare them with Uniswap if you wish. And the distribution of deals is an already solved problem, for example, how airlines transport passengers transport passengers . So for us, it's just going to be an attempt to figure out what will give you the best result.

After speaking with the Uniswap team, I realized that they were excited about the ability to exchange token A for token B with more benefit than the Uniswap interface could offer. This is great. And another question that AC actively answers in the chat, but I'll ask it for completeness : is it possible to optimize Uniswap itself to optimize Uniswap itself so that people don't have to turn to other DEXs or use third-party services? How about porting these changes or routes to the main protocol? That's exactly how I understand it.

OK. mine Absolutely. I think maybe it was a design decision on Uniswap's part to say, " on Uniswap's part to say, " You know what? We'll just use six sub-tokens and always optimize for gas fees." So, they could definitely do it, but as we can see, they are quite busy with V3.

The interesting point here is that with V3 this problem becomes even more complicated as there is active and inactive liquidity being routed through ticks. So it would be very interesting to see how it would work in that case. Our first step in V3 is probably to do what DEX aggregators like 1inch are already doing. They just look at what V3 routes are available and suggest them, instead of us building our own pathfinding algorithm for V3. But I think these are just very simple optimizations that Uniswap could certainly do.

I'm not entirely sure why they wouldn't do it, but of course they could very well implement it. Well, I hope that answers our audience's questions, and thank you very much for this great demonstration and presentation—this is an extremely interesting problem to work on. Therefore. Thank you.