Uniswap v4 Position Manager - ETHGlobal Singapore 2024

Um, welcome to today's report. I will focus on the position manager for Uniswap V4. Um, they call me sauce. I am one of the protocol engineers at the Uniswap Foundation. I worked very closely with the labs team directly on the position manager.

Um, a little about me, here I am on Twitter if you've seen me. Um, I'm also known as a troll on GitHub. Um, and the position manager we call PASM internally. Um, and when we settled on that abbreviation, we added that emoji to Slack, and that's where the ASCII art comes from, if you open the position manager. Um, okay, so that's position management in a nutshell position management in a nutshell .

It is very similar to a universal router in the sense that it is a command system. It depends on the coded actions, etc. I know that a universal router is a bit complicated to work with, but I think the possibilities it opens up are really cool. So, breaking it down line by line, this is an example of creating (minting) a position. You are actually coding two actions, right?

For example, what is the main liquidity operation? In this case, we create a position and then use the delta resolution function, i.e. how we should pay the tokens; and when you create a position, you probably, or I guess, anyway, when you create a position, you pay two tokens. Therefore, we also code the pair calculation action, and in the following lines you code the parameters.

So, um, do you see my mouse on the screen or not? Good. Um, so you have , of course, the pool key, the tick range, the liquidity, some slippage, and also the recipient of the NFT also the recipient of the NFT position. And in the second line you also code which currencies are being paid, i.e.

currency zero and currency one, um, and as for the actual call, that's actually what the position creation is; this is the same signature function for increasing liquidity, collecting commissions, burning positions, and this is where some difficulties arise when managing positions or using command- type systems. Um, but the cool thing about this is that you can do extremely complex sequences to manage liquidity. So, one of the things we focused on we focused on was highlighting the benefits of flash accounting in V4. Flash accounting in V4 can be summarized as the aggregation of a series of transactions, where you only pay the final difference in tokens, without performing transfers after each complex action. We've identified some interesting operations that you can perform, like "feeding" like "feeding" , right?

This is the idea of ​​using commission income from one position to increase liquidity in another, or using commissions from one position to create an entirely new one. We can call this "sharding call this "sharding ". Since it is a command system, it looks like encoding such operations. So, in this first example, I think it's "feeding." You reduce liquidity in one pool and increase it in another, then pay only the final difference.

You are not limited to one pool: theoretically, using a complex sequence, imagine that you are trading ETH/USDC and want to create a position on ETH/BTC. You can close your position, exchange USDC for BTC, and then open a completely new position in a different pool. Thanks to flash accounting, we don't need to actually perform token transfers. This is all done within the framework of internal accounting. This is a brief about position management and interesting possibilities that explain why we lean towards a command system.

Another new feature in position management in V4 that differs from V3 is that we allow other contracts to change positions while locked. This is very useful for hooks useful for hooks . You still follow the same command system with the same actions and options. It's just that now approved contracts, like hooks, can operate and change position while the block is active. Some ideas include using the after swap hook function to take the user's fees every few blocks and reinvest them into the position itself.

Hooks, perhaps in the before swap function, can perform liquidity rebalancing, narrowing the position to a narrower range. There are other ideas for redistributing value, where the hook could take some of the liquidity for redistribution among other participants or implement measures against JIT attacks, etc. Um, this is what it looks like in a hook. Um, this is before the swap. Um, you see that there are some confirmations happening, and you can just imagine a sequence of coded actions, and the hook then accesses that function, and the call to that function then changes the base position.

Um, another new feature in V4 position management is called followers. This is very similar to liquidity mining, um, or staking, or rewards. And the idea is that it's pretty similar to hooks, but for positions. Um, so you implement this ISubscriber interface, and this contract can, if users agree, and for example, I have a position, I say, "I will subscribe to this subscriber contract subscriber contract ," contract A will get notified every time I do something with my position. That is, when subscribing, when transferring, when increasing or decreasing.

And what a subscriber can do is simply track changes in my liquidity. They can deal with, for example, the distribution of rewards the distribution of rewards . Um, and the reason we chose this design is because, essentially, users don't need to actually transfer their NFT. In V3, if you wanted to do liquidity staking, I had to completely transfer my NFT transfer my NFT position. And now this contract holding this NFT has full ownership of the underlying assets.

So subscribers are a kind of safe approach to liquidity staking. Um, this is certainly very suitable for our bounties and such. Um, we at the foundation or at Labs have no intention of releasing any canonical version. So it will be a kind of community-driven subscription. Ahem.

This is what followers roughly look like. Um, you define this function or you define this contract. You would unfold it. Um, and you implement these functions that are called every time someone takes action on their position. So actually notifyModifyLiquidity is where you will do most of your accounting for reward distribution.

Um, that's mostly all about position management in Uniswap V4. So our prizes this weekend are mostly about not only position management position management , but also Uniswap V4. Um, and that includes, for example, hooks. So, the first category: $10,000 for hooks. It's really anything like dynamic fees, um dynamic fees, um , maybe automated liquidity management, um, custom accounting, hook fees, value redistribution.

Our second category: integration into peripheral components. This is, for example, if you create, you know, maybe a contract that performs really cool complex sequences, that would be perfectly acceptable. And our last category last category is research and experimentation. It's like LVR experimentation. It's like LVR , MEB, reliable oracle projects, just general random ideas that may not fit into other categories.

Um, some materials you might want to look at are docs.uniswap.org. There is a pending merge request (PR). I didn't know I didn't have access to merge into the main repository, so I'm waiting for people in New York to wake up.

But if you look on GitHub, you will find a PR with all the new documentation for V4. V4 by example contains a bunch of code snippets on Solidity. And of course, we have the main V4 contracts. I am ready to answer. Were there any questions?

No. Perfectly. Do you have any existing ones? Yes, there are reference materials. Oh yes.

The question was about whether there are examples of hooks specific to position management position management , or the question was whether such hooks exist? OK. So the question was: are there any hooks already and what can we expect during the hackathon? There are some examples of hooks in v4- examples of hooks in v4- periphery. They are located in a directory that seems to be called example contracts.

They were here before, but we removed them because it was difficult to keep them updated. Ahem. And some of them are quite interesting, such as oracles or limit orders. Yes. Here are these examples.

As for other examples in the kernel, there's a lot to look at in our test files . As for what we're expecting this weekend, it's general innovations related to V4. I think the position manager was only completed a few weeks ago, and it's still a fairly new thing. We haven't seen many developers integrate it yet. So this is an exciting area for us to explore how developers want to work with it and make the most of its capabilities .

Class. Are there any more questions? Perfectly. Class. Thanks, guys.