Hands on with Uniswap v4 - ETHGlobal Bangkok 2024

Okay, great. We can begin. Hey, I'm Sauce. I am a protocol engineer at the Uniswap Foundation. I've been working quite a bit on the core Uniswap V4 codebase.

Today's talk is something of an introduction, as well as an opportunity to share interesting ideas about Uniswap V4. Here is my Twitter. I am also known as the author of humorous posts on GitHub. If you've been looking at the pull requests, you might have found something funny there. Okay, let's get to the point quickly.

V4 is more than just hooks. This is a really big feature of V4. We have a singleton design . This means that all tokens are stored in a single contract, unlike the V3 design. This is much more efficient in terms of gas.

Thanks to this design, we have "flash accounting" have "flash accounting" , or deferred accounting of balances. The point is that you can perform a series of operations that create credits or debits, and at the very end of the transaction, perform a final settlement of tokens. Normally, if you were to exchange tokens and then add liquidity, you would have to make token transfers for each step. But with flash accounting, all this only happens at the very end. ERC-6909 end.

ERC-6909 is essentially a wrapper for ERC-20. This allows you to store your ERC-20s inside the main contract and exchange them efficiently. This is very useful for MEV very useful for MEV bots or high-frequency traders. Another feature is feature is native ETH support. In V2 and V3, you needed to " needed to " wrap" ether to trade it.

In V4, we support the native ETH token directly, also to save gas. V4 has a new feature—" new feature—" donations" —related to liquidity provision, where you can direct income to liquidity providers in the range. This is a mechanism that may help in redistributing value. So that's another interesting aspect of V4 another interesting aspect of V4 . And lastly: V4 has no fixed commission levels.

You can have any commissions have any commissions , for example, 4 or 22 basis points. Another area where developers can prove themselves is dynamic commissions. This allows developers to freely set and change the fee amount. Of course, there are certain limitations, but, again, the protocol does not hard-code anything. I think there are other AMMs I think there are other AMMs that support dynamic commissions, but have a certain rigidly defined formula.

But in V4, everything is configured by the developer. And finally, hooks, which are the main topic of our conversation today. So, what are hooks? Hooks are a way to arbitrarily add valid Solidity code to the swap lifecycle. The swap life cycle is more than just an exchange, right?

This is the whole end-to-end process. For example, you can check certain things when creating a pool, or you can configure the pool after it is created . When providing and modifying liquidity, you can also run logic, such as checks or changes. Oh. Em.

Why is this...Okay, cool, sorry, and of course, there's the swap itself. Before executing a swap, you can update the dynamic commission. You can change liquidity, for example, to concentrate it. And after performing the swap, you can write the data to storage, for example, for an oracle.

And as I mentioned about "donate mentioned about "donate ", I've seen few hooks related to it. So this is also an interesting area to explore. This is what the hooks look like. This is exactly what you expect. Therefore, before performing a swap, a check is made to see if the pool is configured for this.

If the "before swap" function exists, an external call to your hook contract is made. Where the arrow points sideways, that's a separate contract that you implement, and then it goes back to the main contract to execute the swap logic. Here's what the code looks like. I'll go into detail, but again, a hook but again, a hook is a deployed contract that conforms to a specific interface where you can add logic for the swap lifecycle. Let me quickly explain the difference between hooks and pools.

Em. A. A hook is a pool, but a pool is not always a hook, so you can describe it. What I mean is that pools are simply independent, unique sets of liquidity positions. This is a collection of two assets for trading, right?

Pools have at most one hook contract. The implements several hook functions. You can combine and choose these hook functions, such as " hook functions, such as " before swap" and "after swap", as you wish. You know, if you use "before swap", it doesn't exclude the possibility of using "after swap" using "after swap" . You can, you know, use all of them or just one of them.

This is perfectly acceptable. And just to emphasize how hooks and pools are related . So, this is an initialization function. So if you create a pool if you create a pool , you specify the pool key and its initial price. The pool key, which again uniquely identifies a set of liquidity positions, is determined by the trading pair.

That is, two currencies, fees, a configuration parameter called "tick spacing" and, as you can see, hooks. Each pool has at most one hook contract. So, let's delve a little deeper into how "before swap" and the hooks themselves work. This is, in fact, what their name implies. "Before swap " is executed before the swap, and "after swap" is called after the swap is complete.

It is worth noting that in both "before swap" and "after swap in both "before swap" and "after swap " you get access to the pool key. So in " to the pool key. So in " before swap" you know which trading pair you are working with, the direction of the transaction, as well as its volume. Theoretically, you could develop a single hook contract that would serve that would serve , for example, ETH/USDC, ETH/ , for example, ETH/USDC, ETH/ Tether, or ETH/BTC. So, a single hook contract can serve and facilitate different trading pairs.

Another interesting set of data that is passed in " that is passed in " after swap" is the result of the swap. You get access to both the incoming and outgoing amounts. So if you want to create oracles or maybe different value redistribution mechanisms, you will have access to volumes. The same goes for liquidity hooks. Here they are divided into four different functions.

But again, as the name suggests, this is logic that can be executed during the liquidity lifecycle. Now let's move on to the interesting hook ideas I have . Er...Obviously, as I mentioned, we have dynamic fees, and there are ways that hooks can charge external fees. We call them "hook commissions."

So, there are ways to redistribute value or different incentive schemes to encourage both traders and liquidity providers. There is a whole array of research from Dan Robinson. Therefore, there are several ideas for creating an AMM that is resistant to sandwich resistant to sandwich attacks. And these slides are a little bit outdated, but I think about two weeks ago Dan Robinson published an article on prediction markets where he basically proposed an interesting curve that is very well suited to providing liquidity in prediction markets. Dude, why, why is it doing this?

It doesn't matter doing this? It doesn't matter . I'll just keep going . Er, blah blah blah . Er, blah blah blah .

As I said, there are things that can be done with automated liquidity management. For example, before a swap, if you see a large trading volume, you can concentrate liquidity; Additionally, we can directly support rebasing tokens—not natively, but you can create a hook to automatically wrap them. So, for Lido staked ether before swap, let's wrap it in wrap staked ether. You can also design your own curves for different asset classes and tokens with rebasing. These are two big areas and topics that the fund is actively promoting regarding hooks: first, something that improves the profitability of liquidity providers (LPs), such as fee optimization or liquidity management.

On the other hand, we are interested in hooks specifically designed for certain asset classes and their types. Another important area of ​​research is application-controlled execution. I think it's also called application- specific sequencing , or ASS. This is again related to Dan Robinson: theoretically, through a hook you can control the order of transaction execution. You could order transactions based on a specific auction or commission.

Oh, and this applies to hooks, and V4 in general—because our prizes cover not only hooks, but also V4 itself. Liquidity mining with subscribers. This is a new feature that is slightly different from V3. Er...maybe something to do with creating oracles for liquidity positions.

They don't exist yet, and it would be a pretty interesting project. As I said project. As I said , with the 6909 tokens being issued by the underlying contracts, it might be a good idea to create some kind of staking mechanism for them. Developer tools are, of course, always a very interesting topic. This can be anything from testing kits and backtesting LP performance to any solutions that simplify and speed up the hook creation process.

These are some really great ideas for development in V4. Um, another area is indexing, for example, setting up a Ponder schema would be really cool for us. And finally, I think it's worth moving on to our prizes. Um, our main prize is for hooks. If you implement a hook that has a dynamic commission, a custom curve, or something like value redistribution, such as protection against JIT attacks, then this is suitable.

The second category is integrations: anything where you use V4 as a dependency for your project, but don't create a hook directly, is also fully compliant. And our last category, of course, is for Unichain; just create some interesting DeFi some interesting DeFi application on Unichain. Um, that's all about the hooks from me. Here are my contacts on Twitter and Telegram. So you can contact me there.

We are very active on Discord. We have documentation. If you are interested in creating a hook, I recommend our V4 template. It configures dependencies and provides a ready-made hook template. All tests are already set up.

So this is a very, very good place to start. And now, yes, I can give the floor for give the floor for any questions. OK. So, his question was about the Uniswap frontend: if you want to make a swap through a hook, do you call the hook directly or through a contract? Hmm, that's a good question.

You can call the hook directly. Although this is not a very common pattern. Hooks are abstracted in such a way that theoretically, if I write a swap if I write a swap router or Uniswap Labs has one, they will indicate that the transaction should go through your pool and it will automatically execute your hook logic. Um, but you could theoretically design your hook accordingly. So the question was , do you need to create your own swap router for the hackathon if you're making your own hook?

No, not necessarily. We have a Universal Router, and I think I'll be adding documentation for it soon. And there's also a very, very simple test router included in the V4 template, and there's an example of how to use it, which is suitable for trading in a single pool, so you can trade directly on your hook. Just a very simple question because I've never done this before done this before . Um, just wondering how to connect a hook to, well to connect a hook to, well , a pool?

Do I just need to register the hook as the hook address? This is a separate type. Yes. Em. So, hook registration.

When you create a pool, you specify the pool key here, and inside the pool key are hooks pool key are hooks , which is the address. So when you create a pool, you specify the address of the hook. Of course. That is, you deploy the pool manager separately and then register pools in it . Is that how it works?

Yes, that's right. Yes. Before you can create a pool with a hook, you must deploy the hook address. This is a separate smart contract and you register it with the main pool manager. This is the main contract, and when you register or create a pool, you specify the hook address.

Class. Thank you. Class. So, the general question is: if we all create a pool hook here , we all create multiple pools, maybe multiple pools, maybe for the same pair, how do we make sure that liquidity doesn't get fragmented, like? Yes, I often get asked this question, um.

Theoretically, the ETHUSDC trading pair will exist as many pools. I think there are market forces at work where liquidity providers will naturally gather around the most efficient pools, the ones with the efficient pools, the ones with the most volume. In general, such a problem really exists. We do not expect it to be significant. My advice to developers: if you try to compete in ETHUSDC, you will have a hard time.

But essentially, one of our categories is designing pools and tokens together. Hooks and pools or hooks and tokens together. So if your token is mostly traded only on that specific hook pool, you will get most of the volume and order flow. Thank you. It seems there was a question at the end of the hall.

Sir. Can you stop this? Thank you. Do I understand correctly? So there is no way to delete an existing pool or add hooks to an already existing pool?

Yes, there is no way to delete a pool after it has been created. I mean, if there is no liquidity in it, then technically it is considered deleted considered deleted . If you initialize the pool, there is no way to add a hook later. The pool and hook are linked together during initialization. Class.

If there are no more questions , I will be at our booth. So, come and find me.