Automatically remove gauges that are not voted for

Over the past weeks we’ve seen two gauges being removed FRAX/SUSHI and FRAX/IQ. Currently a vote is up to remove the FRAX/mUSD gauge. All of these gauge removals require discussion and voting and can easily cause drama and controversy. I propose that we determine a rule of when a gauge should be removed and the stakes for that gauge unlocked.

Proposed rule: Remove a gauge when the percentage of votes for this gauge is below 1% for three consecutive voting rounds.

Take the current voting round (see screenshot below). If the votes would stay the same for two more rounds, then the “Gelato FRAX/DAI”, “Sushiswap FRAX/SUSHI”, “StakDAO FRAX-ETHput” and “mStable FRAX/mUSD” gauges would get removed and the stakes unlocked.

Now the idea is not to remove a lot of gauges, but to introduce a mechanism for pools/gauges that are not deemed important enough to FRAX by the community are gracefully ended. I don’t think we want to have a long list of gauges of which most of them are receiving close to zero emissions.

Another reason why I propose this mechanism, is that it will incentivise protocols to stay relevant to FRAX and it’s community members. Creating more synergy, engagement, and possibly financial incentives through bribes.

I also believe the rule should be conservative and not create a hostile environment where protocols need to fight to maintain a gauge. We are cooperative Fraximalists :wink:

Please feel free to discuss, challenge, and propose different rules.

2 Likes

Copying mathletamine’s comments here

Maybe the crux isn’t about removing gauges but unlocking stakes. Curve doesn’t have LP token locking, only CRV can be locked for veCRV.

I agree that locked LP can be vital to protocols, just like it is for FRAX.

Counter argument would be that these protocols should bring something in return for the utility/stability they get through the locked stakes. Similar to how FRAX is paying for stability through Convex/Curve. I can also see more people max locking when there is a guarantee the stake will get unlocked if the rewards are drop to zero.

Locked concentrated liquidity is an important safety feature of the protocol. Even if the pools are relatively small, together they all contribute to the safety of the protocol.

As long as we are undercollateralized (CR<100%) we need locked liquidity, so we can not just unlock pools, because they are less popular.

I’d argue that gauge voting is more than a popularity vote. If it is important to keep stake locked, wouldn’t people automatically start voting for it if it’s about to unlock because of the proposed rule?

Locked LP is important to FRAX I agree. Maybe we should look more into optimizing stake locking for pools most important to the mechanics/economics of FRAX.

For example, if we want more and locked liquidity against other strong stablecoins. Should we then reward locking more for stakes that defend the FRAX peg (E.g. FRAX/USDC, FRAX/DAI) over stakes that increase FRAX adoption (e.g. StakeDAO’s Frax PUT / Vesper Orbit)?

Unlocking also doesn’t mean that this value would exit the FRAX ecosystem directly. People can re-deploy this value to other FRAX pools.

Maybe an ideal solution would be that instead of unlocking, users could re-deploy the staked value to another FRAX pool. I’m expecting though that this is technically not feasible.

We do not want that people need to spend their vote on some pool rather then the the pool they are farming themselves, just to make sure the protocol is not at risk. Protocol security should not depend on altruism.
The reasoning for not unlocking is stronger, because then you need to buy FXS and vote for the pool you are in. That is a selfish action, so that works much stronger.

I agree with this. Having locked liquidity for a concentrated pair within 1% of the peg is very valuable and crucial for the protocol. The locking of non concentrated liquidity does not help with the peg. So I am in favour of removing the time lock bonus for all non concentrated liquidity pools (maybe with FRAX-FXS as the only exception).

This is technical possible, but not worth the engineering effort in my view.