When it comes to protocol-owned liquidity, I’m more than happy to explore different options. Using Uniswap V3 with a ranged position from $2 to $50 is one solution, but I’d love to see more specifics on the execution.
The TL;DR on how Uniswap V3 works: if you sent a liquidity range for POOL from $2 to $50, POOL will be sold for USDC (or whatever the paired asset is) as the price moves toward $50. When POOL trades back down the range, or toward $2, USDC is sold for POOL. And while trading happens, the position earns trading fees, which can be withdrawn from the NFT position as they are held separately from the liquidity within the position. In Uniswap V2, trading fees were reinvested in the position, but in Uniswap V3 that is not the case.
Since POOL governance is still conducted on mainnet and the discussions regarding cross-chain or multi-chain governance have not progressed beyond the forum, that I’m aware of, I’m assuming we’d be setting up a ranged position on Ethereum mainnet. Because Uniswap V3 is on Polygon as well, that is another possible option.
In any event, we’d want to provide shallow liquidity along the full range, as that reduces the likelihood someone could execute a TWAP attack on POOL liquidity. In the future, if we want to see POOL listed or used in a lending market, using best practices to ensure it’s harder to manipulate POOL price will be important. Euler Finance has a great tool that can be used to gauge the relative safety of a liquidity pair on Uniswap V3 against TWAP attacks. Locating a liquidity pair on Uniswap V3 with similar depth as the proposed POOL:USDC pair would give us some insight into the security of that pair.
If we provide a small amount of liquidity along the full range and the majority of our liquidity in bands between $2 to $50, we’d still need some POOL:USDC liquidity in the current range to allow for buy and sell trading. Defining the amount of USDC needed before an execute vote is important, as we’ve recently deployed USDC into PoolTogether V4 to earn interest and fund prizes via interest generated. Any use of USDC from the treasury should be specified ahead of a PTIP execution.
To note: Uniswap V3 allows users to enter single-sided liquidity outside of current trading ranges. Should PoolTogether ever want to create a buy order below a specific price, we could set USDC below a certain trading range to act as a buy order that acts at a buffer at a certain price. Worth mentioning, as this functionality can be used in the future in more strategic ways to get around the 7-day timelock present when funds are deployed using the governor alpha contract.
Technical Specifications
One important element I’d love to have some more discussion on: pool cardinality
Anyone can pay a fee to increase pool cardinality, or the ability to store pricing information in the contract for longer periods of time. By increasing pool cardinality, a user can increase the number of pricing observations that are stored directly in the pool contract; this functionality is what makes Uniswap pools a commonly used price oracle source. More on this in the Uniswap documentation. Hayden Adams also has a discussion about this here.
There hasn’t been any mention of what fee tier we’d be using when setting up this pool. Right now, most users are used to paying 0.3% in Uniswap V2 pools, but we’d have the ability to choose from 0.01%, 0.05%, 0.3%, or 1.0%. I’d guess that most would be in support of the 0.3% fee tier, but having a poll on tiering or a broader discussion is worth having as well.
In Uniswap V3, we can also conduct liquidity mining campaigns to direct liquidity to in-range liquidity bands. Once we are happy with POOL price, we could shift nominal amounts of POOL liquidity mining to Uniswap V3 to increase the depth of our liquidity. More on liquidity mining in V3 here.
There’s a lot of functionality we can take advantage of in Uniswap V3, but it is a more complex protocol that is more difficult for users to understand. Because of this, I’d like to see a wider discussion on specifics of this PTIP before progressing to an on-chain vote.
Thank you, @Brendan for starting the conversation. This is a valuable one to have, as our DeFi 2.0 experiments have yet to yield significant value to the protocol or to POOL holders.