Uniswap 🛠 An Introduction to Uniswap v4

My name is Thielen. I'm from the Uniswap Foundation. Today we will talk about Uniswap V4 and introduce you to it. Before we begin, I want to welcome you to where it all began for us. Here in New York, when all you could do on Uniswap was essentially exchange UNI for ETH.

And it's safe to say that we've come a long way since then. Although we have already accomplished a lot, we are still very far from finished. This summer, we announced the launch of Uniswap V4. More specifically launch of Uniswap V4. More specifically , we announced that Uniswap V4 will be launched.

Along with it came a new and exciting paradigm that we called hooks. Hooks allow you to create pools that are now customizable, modular, and open up design space for developers that we have n't seen before in Uniswap and DeFi. And I think now is a great time to be a developer on Uniswap. But hooks aren't the only novelty here. We've added so much new to Uniswap V4 that you new to Uniswap V4 that you probably won't recognize it, it's nothing like what we saw in V3.

Now we have moved to the singleton pool manager architecture. We have reintroduced native ETH. We have flash accounting. All of this is done to make Uniswap faster, more gas-efficient, simpler, and more fun to develop. How about delving into what makes the V4 special?

As we mentioned, the first thing we talked about is a different way of managing pools than in Uniswap V3. In Uniswap V3, pools were created according to the factory principle. You were referring to the pool factory contract. The factory contract created a new separate pool address for you, all the pools lived separately at different addresses, and you had to address each one . So, this is how it works : you configure your factory and pool manager contracts.

You create a factory contract and use it to interact with the pool creation. You then use this contract factory to deploy your Uniswap V3 contracts. When you deployed them, that's another nuance. You only needed to worry about three parameters. You choose a pair for the pool, such as ETH/USDC, and then choose a fee level.

In V3, you could choose one of four commission levels, which automatically determined the tick spacing. So, your tick interval is predetermined. You have three options. Class. Then you deploy your contract, create a pool, and you're done, but it's a different contract, which is not very convenient for the developer, because you constantly have to look for new contracts and interact with them.

This is quite troublesome. So in V4 we introduced a singleton-style design: now all pools are in one contract, and each has its own ID. You will use this ID to reference the pool in the contract. So from the very beginning, we are simplifying everything and also making pool creation more gas efficient. Now you don't need to deploy new contracts every time you create a pool you create a pool .

All of this exists in the V4 pool manager. Another difference is that, as we saw in V3, there were only three parameters when designing the pool. Now there are a few more options. You still have the commission levels and currencies, but now you can customize the commission levels to your own discretion as a developer. It's not just four commission levels anymore, you can set any.

You can set the commission level to 99% and see how much LP will flow into this pool. In addition, the tick interval is now also determined by you, and there is also a new feature is also a new feature - hooks. Hooks are individual contracts that now exist in pools now exist in pools ; They can be customized and developed, you can set any parameters that will determine the operation of the pool. We'll delve into hooks a little later, but I think this is where you 'll initialize the pool. You will add your pool key here.

These are all those different parameters that we just mentioned. Then you initialize it and your pool will be stored in the contract. This is another interesting point. Previously, when you initialized pools in V3, you didn't have the option to use hooks to use hooks . Now, when creating a pool .

Now, when creating a pool , you see that it checks for the presence of a hook that should be called before the pool is created. This is already built into the initialization function. And as we mentioned, this is stored in the pool contract. Another point: no need to wrap ETH anymore. You can interact with native ETH.

It's much simpler, and I think it will be much easier for developers to test and do other things. So, this simplifies trading, reduces costs, and welcomes the return of native ETH. Another point is flash accounting. Flash accounting is very important to us because now we can actually test transactions and execute them in one batch during processing. This way, you don't waste a lot of gas performing several different swaps or other operations.

The "lock and call" feature in our flash our flash accounting allows us to accounting allows us to essentially merge transactions, test the different swaps that are happening, and check the delta to see if everything converges and makes sense. This is extremely cool for the V4 , because as we said because as we said , gas efficiency , gas efficiency is an important aspect that we have improved, and that is what allows us to do this. Oh, yes, here you have the delta of your account. You check that everything matches up and track all balances to make sure they are accounted for and correct. And then you get better results from your transactions and save more gas.

Now that we've got that out of the way , let's get to the fun stuff and what you, as developers, should be excited about. These are V4 hooks. So, for the first time, you can use Uniswap as a protocol and build new customizable features on top of it that extend its capabilities from a simple Uniswap DEX to your own custom exchange with your own pools and interface. It looks like this: hooks can be called at four different points of action within the Uniswap protocol. Before or after pool creation, as we saw during initialization: was there a hook to check—should it be called before or after the position change for LP?

So you can do cool things with it . You can call the hook before or after the swap is performed. Yes, before or after donate. Donate is also a new feature in V4, which allows you to provide commissions to LPs in a pool, effectively donating to them, incentivizing them if they stay within a certain liquidity range. You can pay them commissions for maintaining this range.

So, this is very... There are a lot of cool liquidity mining incentives that can be created through this. So let's take a look at what you can build as an example to understand how hooks work. We'll look at a simple New York Stock Exchange hook, okay? What if I wanted to change Uniswap and make it open only during New New York Stock Exchange hours?

So, you know, we'll look at this and say, "Okay, before I do the exchange, I want to enable this hook and see if...I want to run my hook for this." So, I call the function before the exchange and set its value to "true". And then I have my own function in a separate contract hook that I add to the Uniswap pool that I created. So, I have this ETH-USDC pool.

He can only work during trading hours of the New trading hours of the New York Stock Exchange. And before the exchange happens, I, as a participant in the exchange, call this separate contract, or the contract now calls this separate contract and says, " contract and says, " Okay, is this the time between 8:00 and 17:00?" Is it a day off? Is this etc.? And he checks whether all this is true.

And if that's the case, then an exchange can happen. If not, then the exchange does not take place. And here the developer actually added a "ding-ding- added a "ding-ding- ding" sound every time an exchange occurs, so you know that your exchange has been made and the New York Stock Exchange bell has rung. But this is not the only type of hook that can be created. Instead of code, let's look at other examples that might be more conceptual.

What if I now had an NFT, and for some reason I wanted only owners of a particular NFT to be able to interact with my ETH/USDC pool? I, as a developer, say, “ developer, say, “ Okay, I have a Bored Ape NFT, and only people with a Bored Ape NFT can interact with this pool.” And then we have Ether Rock. We don't want people from Ether Rock interacting with this pool. So, this hook would create the same scenario where it checks before exchanging if this condition is met, and if so, the exchange is successful, and if not—you get blocked and can't exchange in that pool.

So, you know, there are a lot of interesting social NFT social NFT applications that can be built on this. And, you know, another, I think, more interesting application or hook for people who are interested in the liquidity provision space liquidity provision space is what if I had all this liquidity in a USDC pool and I was a liquidity provider, but I wasn't managing my positions very well. So I could create a hook that essentially says: if this person is in range, then they're fine, they get commissions, but what if my position is out of range? Well, you can create a hook that says: we will redirect will redirect any liquidity outside the range, for example, to Aave, where it will still bring us profit. So this is a way in which hooks don't necessarily have to be only on the exchange side.

This is a very interesting way for you as developers to start thinking, "How do I get more people into Uniswap, into this liquidity pool, where we can do a lot more with their money and generate them commissions in ways that were previously not possible on Uniswap." So, this is Uniswap V4 and what we do with hooks. We have $20,000 in rewards that we're giving away to people that we're giving away to people who want to build on our platform, which we call a hackathon. We'll be giving away $12,000 in prize money for people who create innovative, unique hooks that we haven't seen before, and we haven't seen much of that yet since this has only been around for 2 months. So I think you have unlimited possibilities in creating these hooks in creating these hooks .

And since we are still building on top of this protocol. We are looking because we are still developing Uniswap V4. We're looking for any help with developer tools, anything that will help make the developer experience much better for us and for you. And we're allocating $3,000 in prize money for this. For each of the prize pools, we probably plan to award two to three prizes.

So you can calculate for yourself how much you can earn from this . And at the end, we will also have a prize for open innovation. It's $5,000 and it's for anyone building on Uniswap V3 or V4. The condition for receiving these rewards is essentially the use of Uniswap V4 code or Uniswap V3 code. You know, don't just integrate a regular sharing app.

I think we would like to see something a little more complex than that. Oh, and if you're interested in continuing the V4 discussion after this, don't come to me, but join our Hook Dojo instead. We have over 200 participants there, these are active developers who create hooks, share ideas, and answer questions. Um, and I'll be happy to provide you with an invitation link. We also have documentation for V4.

So, just this week we launched a testnet, a rollup on top of Optimism, where you can now develop much easier than deploying only on a local testnet. All our information on how to do it is there. And we also have information about resources about hooks and how to get started developing using hook templates. At this point, I'll be happy to answer any questions you have about the protocol. I wanted to leave more time for this.

Yes. Pool selection. I have a pool, and, uh, I assume a user is trying to exchange something. Do I have a guarantee that my pool will be used? Is there fairness built into this pool?

Good question. So his question was that I created a pool with a hook. And how do I, as a developer, guarantee that when someone makes an exchange, my pool will be selected so that I can collect fees for my LPs in that pool. It's a routing issue that depends, you know, on the interface, on where you deploy your pools. It's unique, I think, it creates a unique advantage where you can have or, you know, we could discuss Uniswap X, how it solves the routing issue.

But in short, pools are a bit more difficult to activate because we have to ensure the security of the pools so that these protocols don't steal users' funds or do anything malicious. So the discussion about how to solve this is ongoing, but mostly I think we'll see a combination of hookless standards and protocol calls to determine how to implement this into routing. So will labs automatically direct traffic to it? I think we're still trying to figure that out. Will it be in the user interface?

It's still, yeah, it's still being worked out. Yes, yes. Steeply. Excellent question. Are there any more questions?

Perfectly. Well, thank you guys for your time. And so.