[BIP-101] Enable tetuQi/QI Stable Pool Gauge with 2% emissions cap (Polygon)

Summary:

This is a proposal to enable a Balancer gauge for the tetuQi/Qi StablePool on Polygon.

TetuQi is Tetu’s liquid-staked derivative token for QiDao’s locked $QI staking functionality.

TetuQi holders are entitled to receive the equivalent staking revenue from QiDao as if they had locked their $QI tokens for 4 years, while retaining the ability to sell their tokens by swapping back to $QI.

Currently, TetuQi liquidity is hosted on both TetuSwap and Dystopia, however the community wishes to find a new long-term home for the liquidity pool, as TetuSwap is limited as a Uniswap V2 fork, and Dystopia is struggling to remain established on Polygon.

References/Useful links:

Protocol Description:

From the Tetu docs:

Tetu is a Web3 asset management protocol built on Polygon that implements automated yield farming strategies to provide investors with a safe and secure method of receiving a high and stable yield on their investments. Tetu’s innovative solutions provide automated yield aggregation and distribution through xTETU.

Tetu’s development focus is to build a self-sustaining yield management ecosystem that provides stable and attractive yields for users. Tetu aims to make the development of automated and decentralized Yield management solutions the main structure of the protocol.

With regards to TetuQi specifically:

  • $QI is the governance token for QiDao, an established overcollateralized stable coin on Polygon and other networks

  • $tetuQi is Tetu’s liquid-staked derivative token for QiDao’s locked $QI staking functionality.

Motivation:

Liquid staking tokens can be at risk of depegging from their base asset when there is not enough incentive to provide swap liquidity. Tetu has been incentivizing these LPs with first $TETU emissions, and then veDYST votes and bribes on Dystopia, but we would like to give the Tetu community option to direct tetuBal votes for this Stable Pool by enabling the gauge and adding it to the tetuBal reflection votes.

Specifications:

  1. Governance: . Tetu protocol is governed by dxTETU, in this way only dxTETU holders can actively participate in governance decisions and shape the future of the protocol. All Tetu protocol management decisions are carried out through on-chain governance, providing an environment of transparency in the governance process.

  2. Oracles: TetuQi does not rely on the use of any oracles

  3. Audits: https://docs.tetu.io/tetu-io/security/audits

  4. Centralization vectors: n/a

  5. Market History: TetuQi has recently trended away from a 1:1 peg due to the fact that a large liquidity provider has chosen to remain in the TetuSwap liquidity pool, which uses a traditional “Uniswap V2” x*y=k price function. However, the peg is slowly returning as Tetu’s eQI yields are used to buy tetuQi at a discount, and as the community takes advantage of this fact to buy TetuQi at a discount.

  6. Value: We expect that if Balancer were to enable the gauge, this pool could become the primary source of liquidity for tetuQi.

Contracts


Stable Pool: 0x4b3Fd0347B7fb1b7BafA61da841E40d5BF6Fe0F5
Child Chain Liquidity Gauge: 0xA9507E50378f4bfDC5F85B7a1ac83aEFa012BfF8
Child Chain Liquidity Streamer: 0x62583dc888ea8658b85D936A6451950224b99B3e
Polygon Root Gauge w/2% cap: 0x61cB986caE3e92b91f9B527506E6d4FBe679F991

Disclosure

The author of this proposal is a community member, and not a member of the Tetu or QiDao teams. The author holds $TETU, $QI, and $tetuQI tokens.

1 Like

https://snapshot.org/#/balancer.eth/proposal/0x329858de6b6f425c1f628acac34d0105a61ee95b77907986f66bbf39dea9fc2f

The title of this proposal states that it would be a gauge with a 2% cap. However the gauge that has been deployed and is referenced in this proposal seems to be an uncapped gauge. Hopefully this is just a mistake but should be amended none the less.

1 Like

yes, thanks for checking that. it will be amended

updated the proposal to include the capped gauge. we might have to let the snapshot run with the wrong gauge but only the correct capped gauge will be added to the system, rest assured.

2 Likes

Thanks all.

Did not realize that the cap was something that got configured on-chain.

Will be happy to redeploy the relevant contracts if the vote passes.

Thanks again for checking and catching that :slight_smile:

Edit again: looks like someone already handled that. Even better!

1 Like

Snapshot vote has been changed accordingly. Thanks for bringing this inconsistency to our attention. https://snapshot.org/#/balancer.eth/proposal/0x81e7e7b8704310744e1b0de58b488e5902f2bd18ebe63bdf5f4dafe67915b29d

1 Like

I have seeded the pool with liquidity. Please let me know if there are additional steps to get the pool to appear in the Balancer UI.

Hey all,

I noticed that the quorum set on the Snapshot vote is 2 million, which contradicts what is written here in the instructions, which says that the quorum is 200k. Did this change and it just hasn’t been reflected in the instructions?

Quorum has been raised a while ago with BIP-58: Snapshot

The documentation is outdated (cc @gerg )

1 Like

10x is certainly quite the change! Thanks for the documentation though :slight_smile:

I am pro tetu and pro this pool, however the A factor needs to be lowered to around 50 for this to be sensible, it is currently 5000. I would like to hear the QI community weigh in as well, their governance will be affected by the outcome of such a high amp factor pool. The current Amp parameter would make the trading peg in this pool as linear as possible between the tokens. In short this means LPs can be drained or their liquid QI and holding a tetuQi bag with little to no protection or market resistance from the underlying mechanics. This is as similar as Balancer Protocol allows to a constant sum pool equation.

4 Likes

I changed my vote to against, though this will likely still comfortably pass. It is a clever strategy by Tetu and/or Tetu community members to have very high amp factor and loop at a small loss liquid QI into tetuQI as users deposit into the LP to keep the pool very heavily weighted towards tetuQI. This maximizes Tetu’s voting power gain for the same incentive spend (I guess in this case, Balancer’s spend).

The flip side is users won’t have the depth of liquidity they’d probably expect when they try to exit their positions in the LP. Tetu is the first project I’ve seen use this looping method. If a user isn’t smart enough to check the amp factor and understand the dynamics at play there’s a good chance they will end up in a situation they aren’t happy about. Since this is a Balancer pool users might expect Balancer to do a reasonable DD when adding new gauges. This is DeFi, etc so is what it is to a certain extent. Still, I don’t think it’s a good look to allow a gauge with such a high likelihood of a bad outcome for LP’s.

1 Like

In full agreement with @ZenDragon and others. The entire setup of Tetu gauges is too dangerous right now to allow those votes to pass. There needs to be better alignment before we proceed!

Hi everyone,

As the author of this proposal, I would like to respond to the various concerns brought up by @ZenDragon, @solarcurve, and @Xeonus amongst others.

First, let me reiterate that I am just a Tetu community member, and aside from one programming bounty task about a year ago – subgraph maintenance, fun! – I have never been part of the core team or received any financial compensation from Tetu.

Thus, I will aim to focus my comments only on this specific proposal for the tetuQi-Qi gauge, and let the core team respond in their own right regarding the main tetuBal-20WETH-80BAL gauge. (aside from one minor point which I will make later.)

Additionally, this my first time creating a pool and interacting with the Balancer Protocol’s governance process, so I would appreciate a small bit of graciousness and understanding when it comes to assumptions of a specific strategy or motive on my behalf. I frankly did not expect this proposal to immediately go to a Snapshot vote - I figured that if I had done anything incorrectly when it came to contract deployment or choosing parameters, it could be discussed prior to a vote so that nobody feels rushed, or that I am trying to create a dangerous gauge.

Regarding the background and intent of this pool:

QiDao was one of the first DeFi communities that I was part of, and I have also known Belbix, the founder of Tetu, since back when he was the community tech lead at Harvest.Finance.

A few months ago, the price of tetuQi started to “de-peg” from the price of QI, a fact which was quickly noticed by both communities. The commonly accepted theory was that there was simply no more demand for $QI, as the staking yields had dropped nearly 5x since the launch of tetuQi. As someone who cares about both products, I offered my assistance to brainstorm some ways that we could help fix and restore faith in tetuQi.

More recenlty, I came to realize that a large reason for the de-peg was due to a large LP provider sitting in a classic x*y=k pool on TetuSwap. Despite the fact that a stable pool on Dystopia was highly incentivized, the liquidity provider had not made any transactions for over half a year, and the slight imbalance in liquidity was leading to a discounted price of $tetuQi, which then led users to sell their $tetuQi as they feared a bank run, and the cycle repeated over and over again… despite the fact that there was ample liquidity for any tetuQi holder (aside from the liquidity provider themself) to exit back to $QI.

Recently, I have personally been incentivizing the stable pool on Dystopia in order to attract more liquidity to help us combat the imbalanced liquidity in the TetuSwap pool, so that ideally we can re-peg tetuQi to Qi and keep the product working as designed.

Over the recent months, Tetu had been struggling as a platform with low TVL, low revenue, and limited resources to continue development. My motivation for this “project” was simply that as a holder of dxTETU and believer in the platform, I wanted us to avoid the negative optics of having one of our flagship products fail in this way. Essentially, I just didn’t like that we were getting ragged on all the time, and I saw an opportunity for a fix.

More recently, with developments with tetuBal and with the stagnation of the Dystopia platform, I saw an opportunity to move the tetuQi liquidity to a more established platform, and to direct some incentives to continue the initiative that I had started.

My personal goal is to ensure that tetuQi and Qi trade at near parity, and that any holder of $tetuQi will be able exit to $QI without a significant penalty if they wish. I am not personally accumulating more $QI tokens, nor am I concerned with Tetu having more governance power over their platform. In terms of USD, the tetuQi TVL is around 2.5% the size of tetuBal, and I believe that Tetu, with its limited resources, should be focused on tetuBal for the time being.

Regarding the “looper”:

The “looper” is something that was developed by a few members of the Tetu community when we realized that a large investor had incorrectly deposited funds into the tetuBal LP in a 1:1 ratio. The looper was not something that had been discussed with the Tetu team beforehand, so it cannot have been what they had in mind during pool creation. We have no intention of using this strategy for TetuQi, not least because we are currently working to re-peg the price, and there will likely be many users who will take the opportunity to exit back to $QI.

Regarding the amplification parameter for this pool:

When creating the pool, I figured that I wasn’t really in the position to be setting parameters, and so I would just copy the amplification parameter from the tetuBal-20WETH80BAL pool that Belbix had created, since after all, I am doing these tasks for the first time, and just trying to be of assistance to the platform. This was also before realizing that the amplification parameter for TetuBal was higher than necessary:

Of course, I was actually unable to create the pool with the same A parameter as the tetuBAL pool, so I just used the maximum that the contract would allow. It sounds like this is still seen as too high – so let me state that I am more than happy to discuss an appropriate parameter with any stakeholders, or just to let Balancer governance set the parameter that they feel is appropriate - as long as it’s not x*y=k :upside_down_face:

Regarding the 2% gauge cap:

I believe this has already been addressed, but just for the sake of thoroughness: I followed SolarCurve’s instructions here which linked me to this GaugeFactory, which does not give a second parameter as an option for the create(recipient) function. It appears that the corrected gauge was deployed with an updated factory which I did not know about. Whoops, and thanks to whoever fixed it on my behalf.

Conclusion

Please let me know if there are still additional concerns to address, or if I have missed anything. My sincere apologies for the length of this post, I am striving for completeness and I appreciate the amount of time it takes to read all of this.

Thank you,
– adamb

3 Likes

Appreciate all the context. I would be surprised if the ppl behind the looper didn’t know exactly what they were doing. As far as this pool, we will initiate an amplification factor change from the current 5000 to 50, time frame of the change will be 24h. No one should deposit into the pool until this change has been completed.

A lower amplification factor will make returning to peg easier because you’re starting with an asset that has already depeg’d if your post is accurate. You might want to consider something even lower, like 10, until the peg is restored - then return it back to 25-50. If you want to pursue this course of action please let us know, preferably before people deposit assets. Once LP’s start entering any amp change must be small and gradual.

1 Like

Thanks @solarcurve, I will check with some others and hopefully have an answer on this one soon.

@solarcurve let’s just go for the a=50 so that we don’t have to deal with changing it once there are funds in the LP.

If you (or any others) are willing to reconsider your “no” snapshot vote based on our discussion here, I would be most appreciative.

3 Likes

Looks like there are rules in place that require a minimum amount of time for amp factor changes of a certain magnitude. In this case, it would take nearly two months to complete the change from 5000 to 50. Since I don’t think you want to wait two months to use this pool we’re going to proceed with remaking it. No action is required on your part, all should be handled by the Balancer Maxis over the next few days. Just be aware the pool will not be the one you made.

1 Like

Roger that, thanks!

Ideally the gauge will be available for voting for the round that closes Nov 9. Sounds like there will be plenty of time.