Due to recent increases in ragequit proposals and people not being happy with their own action of being locked, I propose that we standardize the ragequit proposals for users who wants their funds back early. This proposal aims to make governance more effective while establishing clear and transparent expectations, with fairness that does not differentiate.
Solve:
- This proposal makes sure users who are unhappy with their position have a clear way to get their funds/LP position back with standardized costs.
- It makes future governance for FRAX more effective with less need for discussion and less proposals
- It protects the interest of our protocols liquidity system with a standardized fee which is intended to make it unattractive to ragequit
- It protects the protocol from lowering the collateralization ratio below 100% from ragequit proposals.
This proposal does not in any way or form talk about unlocks, which is another topic best judged from case to case in regards to situation.
My proposal for a standardized ragequit is:
10% flat fee
0.5% fee per month left
Example 1: 1 month left of lock
10.5% of LP
Example 2: 36 months left of lock
28% of LP
Due to people being able to claim rewards, it is hard to retract those. To make standardization more easy, the flat rate was increased to 10%. This is more similar with some earlier ragequit proposals. The variable rate of 0.5% per month also accounts for other proposals with higher lock times and with a usual 20% ragequit fee.
There is also the worry about the collateralization ratio (from now refrenced as CR) of Frax Finance, and how ragequits impact on our long term goal of 100% CR. I therefore propose that we utilize a oracle to check CR, and if its below 100% ragequitting is not permitted. In this way, we can protect Frax from systemic risk, while still allowing participants that want to ragequit the possibility when it does not unnecessary damage the protocols interests.
I propose that all new gauges/locks have this option from start, so that this will be optional without going through governance. This means that contracts should have a easy to use front end for ragequitting, which may lead to more development work. The work for the front-end should be prioritized at the core teams discretion, to not distract for more short/mid term important matters. That may even mean a delay for new pairs to get the ragequit function. For old pairs, one have go through governance to enable a ragequit function. It is important to clearify that this proposal will still be relevant, and the terms outlined in this proposal will still apply in ragequitting of those old pairs. The proposals for old pairs will simply be if one should activate the ragequit function or not.
I propose LP the protocol takes in fees from the ragequit be added to the FLE, so that the protocol can continue operating the pair or in other ways increase our revenue and liquidity. The protocol will then manage to keep the pair more stable, even during ragequits. It also benefits from the ragequit because it adds value to the balance sheet.