Standardize ragequit proposals and make it a feature and not a bug

Governance Proposals FIPs
1

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.

3 Likes
2

Reposting feedback given in Telegram for transparency:

This is a nice start. There are some details missing or needing clarification.

It mentions 100% rewards. Please clarify if that means 100% of unclaimed rewards or 100% of all rewards since lockup…so claimed and unclaimed. If the latter, do they have to pay when they ragequit? If so, then we need a clear statement on how they can pay? For example, how must it be denominated?

1 Like
3

Reposting new feedback given in Telegram for transparency:

I typically include extra for the inconvenience. But if we are trying to standardize this, there definitely needs to be a scaling fee on top of that , ideally one that adjusts based on how the liquidity leaving affects the CR.

While we’ve broken 100% CR and hopefully never go back, this scenario needs to be account Ted for because it is the main reason Frax has historically needed locked liquidity

4

Reposting another feedback given in Telegram for transparency:

I’d also include the problem the proposal is solving (i.e., why allow rage quits) and the benefit to frax and the user of the solution.

5

We’ve built a wrapper at Hourglass so that locked LP positions in Frax/Convex are automatically tokenized. It’s currently active on our UI, but maybe it’d be better if we integrated the flow directly into the Frax website? Then everyone who participate in Frax farms get back a tokenized position they can trade on our marketplace.

6

Not a bad idea to have such a solution integrated into the website as an option, and would support such a proposal. However, making it the default setting is in my opinion opening up to too much third party risk, and making part of the protocol too dependent on third parties.

For transparency, there is a new suggestion to the proposal coming in the coming days. Waiting for feedback/the new propsoal.

7

Totally understand the concern for third-party risk, and for what it’s worth, the core locking logic has undergone 2 audits to underwrite its security.

Maybe we could just give users the option to mint the wrapper (but not force them to). We’ve been hosting the wrapper on our app for about a year now, but most people don’t know about it and as such the problem has continued on. Could easily fix this by providing the option on the frax frontend

1 Like
8

I actually think that might be a great idea. Especially if some information and risk around the option is informed as well. Could be a win/win in my opinion to have more direct integrations. Would love to hear the greater communities opinion on it and see if there can be a new precedent. I think your solution can be a good option for some people, but that it should be proposed in another proposal as this is supposed to be a standardization proposal and not a feature implementation per se.

If you need some help to write up a proposal or need some inputs on one let me know. I am happy to help where I can.

9

Thanks Sharky! Would love to collaborate with you on it. Want to shoot me a message @charliepyle on Telegram and we can draft something up?

10

What is the status of this proposal?

11

There is soon coming an algorithmic option to the proposal that I feel is important to have moving in to voting. We are waiting for that option to be finished. I have seen the progress, and it is progressing nicely. But due to the complexity of it, it is important to give it the time it needs so its completed in a satisfying way.

Hopefully the option is finished and will be added at the end of this week, or early next week. That is just an estimate, and it can take longer.

12

I have been working to produce a fairly easy to integrate algorithm that can be adjusted by governance for the sake of a standardized ragequit function that accounts for the health of the Collateral Ratio and relies only on on-chain statistics.

I believe I have satisfactorily finished this algorithm just moments ago.

Within the next 48hrs I plan to self-audit it, clean it up, convert it to digital format, and post it here for peer review and feedback.

The first draft was more complicated than necessary. I believe I have since boiled it down to a much more simple version, but would love for someone to prove me wrong and reduce it further.

Keep in mind, this draft is purely mathematical function and will still need to be converted to working code.

Thank you all for your patience on this, I wanted to have it completed ~2 weeks ago but have had many IRL distractions of late.

Unless I discover any significant flaws or defects in logic, I hope to post the "to-be-peer-reviewed’ algorithm this time tomorrow (~24hrs from now).

If anything changes I will let you know here.

  • Lukas
1 Like
13

Moments after my post, looking back at @Sharkysnakefish suggestion, I realized I could and should implement a time variable into the fee and believe this is a great idea that I overlooked.

I will work to include “lock time remaining” into the function for “amount owed” output.

24hrs may be pushing the envelope given that addition, please plan for my next post ~48hrs

1 Like
14

i support this proposal

1 Like
15

Im going to need another 24-48hrs.

I havent had time to incorporate the timelock variable into the equation.

Im sorry for the delays

1 Like
16

Since I sat down for a quick 15mins this morning…
Time variable might have been the easiest part

D = (time-remaining[years]) Ă— 5)%

Just need to add it to the algorithm and we are good to go.

I will get everything uploaded < 16hrs for peer review.

Thabk you all again for your patience.

1 Like
17

“Position USD LP value” × Multiplier = “Position Boosted Weight USD Value”

“LP Staked + Boost [FraxStats]” × “USD LP Value” = “Pool Boosted Weight USD Value”

G = “Position Boosted Weight USD Value” ÷ “Pool Boosted Weight USD Value”

L = USD Value of LP Position
M = Multiplier
P = “LP Staked + Boost”

L × M = “Position USD LP Value”
B = L Ă— M
P × L = “Pool Boosted Weight USD Value”

G = (B Ă· W)
G = (L Ă— M) Ă· (P Ă— L)

R = FXS allocated to pool per epoch
F = FXS Price

G × R = “FXS rewarded to LP Position per Epoch”
M = G Ă— R
V = “USD Value of FXS rewarded to LP Position per Epoch”
V = M Ă— F

^n = sequential numerical identity of epoch
^y = most recent ^n

T = “Total USD Value of FXS received per position”
T = (V^n) + (V^n) … + (V^y)

C = Function derived from
value of Collateral Ratio %
If C=0 unlocks are not permitted.

C =
{ CR% greater than or equal to 103% =1
CR% less than or equal to 103% = 0}
Y = Years Remaining of Locked LP
U = “LP Position USD Value - T”

X = Amount Owed = (“Total USD Value of all FXS rewarded to LP” + “2.5% of (U) per Year of Lock Remaining”) × function of C

X = (T + ((((Y/4)Ă—10)%)U)) Ă— C
U = L - T
Z = L - X

Finally, run a final “Collateral Ratio Safety Check” by subtracting the value of Z from the “Locked Liquidity” value in the Collateral Ratio equation and refer back to the function of C.

This ensures that no unlocks can happen unless the Collateral Ratio is healthy both before and after any unlock.

Please feel free to propose any changes to these equations. Additionally, please contribute your opinions to the stamdardized fee proposed here.

I felt that, in a healthy Collateral Ratio State, a standard fee of the USD value of all FXS received Ă— 2.5% of (U) was fair enough.

That being said, I have been thinking that I would like to add an additional variable that will change the fee based on a users locked FXS but have not yet had the time to figure that out.

Anyway,

ALL COMMENTS WELCOME AND APPRECIATED !

Thank you,

  • Luke Skywalker
1 Like
18

Hey man, thanks so much for taking the time to do the work to make the algorithm. Really good work!! I will wait to see if we get some feedback. Based on that I will see how I change up my original proposal.

As for input, I propose we keep a flat fee and add the time weighted function to that. I propose a flat fee of 5% or 10% be added.

19

@Sharkysnakefish

I think the reward-weighted fee alongside time-weighted fee is much more fair.

This ensures small players dont over pay, and whales dont under pay.

A flat fee is far more advantageous to someone with an enormous amount of veFXS and a very short lock time opposed to someone with a larger LP and smaller veFXS holdings.

My proposed algorithm charges each individual the USD value of all the FXS they were given, per epoch, combined, on top of a weighted “time remaining” fee.

A flat rate will be gamed, or will be outrageous.

Weighted fees determined mathematically “per position” is the best option and ensures noone can find an advantage.

If I lock for 4 years today, and decide next week it was a mistake, the protocol has paid me next to nothing, and still gains profit off my release. I walk away with a ~10% loss.

If I lock for 4 years and make 50% a year, and 3 years in decide to unlock…

With a flat fee, I would walk away in profit and the protocol would then be at a loss having paid me on a “broken obligation”.

That being said… I would be more comfortable with someone invested long term walking away “with profit”, because the argument can be made that the protocol is paying LPs for liquidity and LPs serve that function, exchanging liquidity to the protocol for incentives over time.

An early unlock does not change the fact that until the moment of unlock, the LP has still given the protocol value that can not be returned, so is it not fair then that LPs have the possibility of walking away with something as well?

With this in mind, maybe a single time-weighted fee across the board is not a terrible idea.

Something like

X = (L x ((Y Ă— 5)%)) Ă— C

X = (USD value to-be-unlocked-LP Ă— 5%-per-year-of-lock-remaining) x (CR Failsafe Function (1 or 0))

20

@Sharkysnakefish
Thinking about a flat fee further…

It would then be more rewarding to users who sell all their rewards, and more costly to users who compound rewards back into their position…

That doesnt seem fair…

Maybe a better solution is to be found somewhere between your flat fee and my weighted one.

The idea of charging long-term oriented users more harshly than “extractive” users does not sit right with me.