It’s been a few weeks since Uniswap v4 was announced and the core whitepaper was released. There are lots of opinions, but a few that stick out.
One of the biggest design differences is the move from a multi-contract to single contract model. In v3, we have the factory pool model with a separate smart contract for each Uniswap pool and global trade router that scanned all these pools to find the best swap route. In v4, all liquidity will be in a single contract and there can theoretically be infinite pools for a single pair (hooks).
Now, with v3 you could have different pools for the same pair, but they were just differentiated by their swap fee (0.01%, 0.05%, or 0.30%). Opening the door the any number of pools requires some pretty robust routing logic to provide users with the best execution route without overloading them information on 100+ possible trade routes.
As pote.eth mentions in the tweet, it could also be possible for the routing simulation to see a pool as ideal for a trade, but under the hood its actually malicious and leads to worse execution prices for users. The router for v4 has to either be incredibly selective or incredibly powerful. Luckily, the work on that has already begun.
From a business standpoint, I first thought Uniswap Labs would use this opportunity to build a powerful router and monetize it centrally via an app. But this doesn’t seem to fit the bill anymore, and thank god for that.
All in all, trade routing is going to get hard. And as Uniswap v4’s liquidity grows, aggregation is going to get even harder. That means the likes of 1inch, Matcha (0x), and CoW Protocol need to thoroughly understand the challenges with v4 before they can confidently integrate it.
There are also a number of potential user-side security concerns that stem from the customizable nature of Uniswap v4, but I’ll save that for another time!
