Create V2 Pool for USDC/GRELF 0.30%

Request for Comment
1

Author(s): UgOs and the GRELF community
SaucerSwap Voting Interface: N/A
Related Discussions: Create V2 Pool for USDC/GRELF 0.30%
Submission Date: September 27th, 2024

Summary

We propose the creation of a V2_USDC/GRELF pool with a 0.30% fee tier on SaucerSwap. This pool will enhance capital efficiency, liquidity depth, and Total Value Locked (TVL), supporting both SaucerSwap and the Hedera ecosystem.

Abstract

The new V2_USDC/GRELF pool will utilize SaucerSwap V2’s concentrated liquidity features, offering higher returns for liquidity providers (LPs), boosting liquidity, and increasing TVL for the platform.

Motivation

The V2_USDC/GRELF pool will boost capital efficiency and liquidity depth, providing more stability and flexibility for GRELF’s liquidity strategy. By focusing on the USDC/GRELF pair, this proposal aims to reduce reliance on more volatile native assets over time, offering a more stable trading environment. This shift will support GRELF’s long-term growth while benefiting SaucerSwap and the broader Hedera ecosystem.

Benefits (Pros)

  • Price Stability: Concentrated liquidity can help stabilize prices for GRELF.
  • Capital Efficiency: LPs can focus their liquidity within a specific price range, increasing capital efficiency.
  • Yield Generation: Higher returns for LPs due to increased trading volumes and concentrated liquidity.
  • Reduced Slippage: Tighter spreads and minimal slippage from improved liquidity focus.

Downside (Cons)

  • Smart Contract Risks: As with any DeFi protocol, smart contracts carry risks.
  • Complexity: LPs may need additional guidance on managing positions in concentrated liquidity pools.
  • Management Overhead: Active management may be required due to the dynamic nature of concentrated liquidity.

Voting Options

  • For: Create the V2_USDC/GRELF pool with a 0.30% fee tier.
  • Against: Reject this proposal for further revisions or consideration.
2

Other than Network risk (which is already a given for dApps), another downside is the datebase costs on the platform. The “technical overhead” mentioned in the August 2024 AMA. The team did mention the cost to store all the data for the pools.

Another downside is liquidity fragmentation,

...

having Grelf split up in different pools would increase price impacts on some swaps (yes, concentrated liquidity would mitigate this, so long there’s liquidity in the area the swap is trying to get).

That’s really the only substative objections I could think of. For the Liquidity fragmentation risk,

...

if Grelf holders are okay with it, then that shouldn’t much of an issue for anyone else (not much reason a non-Grelf holder to care that much of liquidity fragmentation of Grelf).

As for the technical overhead,

...

from my understanding of the Larry 300 (or LARI 300. I should double check) that was hinted earlier, it should help with the data costs by culling some data support of illiquid pools. (Although I hope for a bigger solution like subgraphs from Hedera so every developer can benefit). Personally I might have some hesitancy, mainly because I don’t know how big of an issue this is when it comes to numbers and costs. But I know I would feel a little bit at ease after the Larry 300 update.

Oh and active management. Again, issue for Grelf holders. Although it got me thinking about the autopools. Like what requirements are needed for them, but that’s a side tangent that I hope future CLMM pools creators will think about.

So some of the positives.

...

Grelf has shown strength on the platform. I don’t have the updated numbers on me right now, but Grelf/Sauce v1 pool did beat the liquidity to emissions ratio and holds a lot of Sauce in that pool. And since the SaucerSwap team in their recent proposal is shifting focus from raw TVL metrics and more closer to trading volume relative to liquidity, it would be a smart move for token projects to consider CLMM pools.

Overall, a few green flags, a couple a question flags for Grelf holders (which I probably should had presume it was already discussed amongst yourselves. Damn, I’m loopy lol) , and a pink flag that’s not even really the token project’s fault, just the circumstances.

P.S. I almost forgot. Fee tier. Mainly for the Grelf holders, but why 0.30% as opposed to any other of the tiers?

P.P.S.
Hey @Larry, I don’t suppose the Larry 300 update would go live anytime soon? :eyes:

P.P.P.S. edited format to make the wall of text less long.

4

With respect to the cost, GRELF has several V1 pools with low liquidity, and we wouldn’t have an issue with removing them from the SaucerSwap UI if that makes sense from a cost efficiency perspective.

Regarding liquidity fragmentation, our long-term goal is to have around 80% or more of our total SaucerSwap liquidity consolidated into the V2 USDC/GRELF pool. We’ll coordinate with the community to move tokens at the right moment, but it’s hard to pinpoint exactly when due to market volatility, it could take months to complete the transition. For now, we plan to maintain significant liquidity in the V2 HBAR/GRELF pool until we’re ready to move fully to V2 USDC/GRELF. Having the new pool ready as soon as possible allows us to act quickly when the time comes.

As for the 0.30% fee, from what I understand, lower fees are more suited for high-volume pairs like stablecoins, so the 0.30% fee tier feels like a good fit for a token like GRELF.

Let me know if you have any questions or need further clarification.

1 Like
5

Thanks you for addressing everything that in the Grelf community’s control. The only real substantive issue is the “technical overhead” associated with the data. Again, not really in your control.

I definitely do wish there was more technical solutions to the issues I’ve brought up (whether split routing for swaps to minimize the impacts of liquidity fragmentation, or a Hedera subgraph to ease the burden of storing data cost for developers). I do wish we had more numbers on development funds and cost so the community could gauge how many V2 pools we could run before the dev funds run a risk of drying up by some future date.

All this said, and given the Core team has trusted the V2 Pools creation decision to the DAO, I do feel like the Dev fund is not in immediate risk to drying up anytime soon from adding one of two CLMM pools. But if others disagree, they really should make their objections known.