Standardize ragequit proposals

Authors: Lyule67 & Q. Shinchan

Due to recent increases in ragequit proposals and people not being happy with their own action of being locked, we propose that Frax 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.

We propose the following algorithmic solution for a standardized ragequit:
“USD value of LP position” × Multiplier = “virtual USD Value of Boosted Position”
L M B
“LP Staked + Boost [FraxStats]” × “LP Price [FraxStats]” = “virtual USD Value of entire Pool”
P A N
note [FraxStats] refers to the value indicated by app.frax.finance for the equivalently named statistic of any given gauged LP pool during any given period.

G = “virtual USD Value of Boosted Position” ÷ “virtual USD Value of entire Pool”
B N
G = decimal percentage (virtual) USD Value of position relative to (virtual) boosted value of entire pool
A = LP Price [FraxStats]
D = LP Amount Staked per position
L = USD Value of LP Position
L = A x D
M= (veFXS-stake-weight-boost + time-lock-boost)
M = Multiplier
P = “LP Staked + Boost”[FraxStats]
B = “virtual USD Value of Boosted Position”
B = L × M
P × A = “virtual USD Value of entire Pool”
P x A = N
G = (B ÷ N)
G = (L × M) ÷ (P × A)
R = FXS allocated to pool per epoch [FraxStats]
F = FXS Price per epoch [FraxStats]
F = cumulative avg FXS price of relative epochs (use 3 daily averages [morning/noon/night])
E = F^y × veFXS (user staked)
M = “FXS rewarded to LP Position per Epoch”
M = G × R
V = “USD Value of FXS rewarded to LP Position per Epoch”
V = M × F
V^n = M × F per epoch
^n = sequential numerical identity of epoch, NOT an exponent (used only as epoch identifier)
^y = most recent ^n
T = “Total USD Value of FXS received per (lifetime of) 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% ≥ 103% =1
CR% ≤ 103% = 0}

Y = Days Remaining til unlock of LP Position
U = “USD Value of LP Position” – T
U = L – T
U = amount due to users after unlock, [post-fxs-repay, pre-fee] (no discount applied)

D = USD fee discount for cvxFXS and veFXS stakers
D = (((days-since-veFXS(or cvxFXS)-lockup ÷ (365.25 × 4)) × 50)%) × E
D ≠ >(50% × T)
X = Amount Owed minus Discount

X= ((“Total USD Value of all FXS rewarded to LP” + “0.06844627% of (U) per Day of Lock Remaining[2.5% a year]”) minus D) × function of C

X = ((T + ((((Y/1461)×10)%)U)) - D) × C
Z = L – X
Z = Amount received by User post fees + deductions

Loop (Z - X) back through CR calculation to ensure CR% ≥ 103% before finalizing unlock

We 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.

We 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.

For voting, the following voting suggestion is proposed:

  1. Yes to algorithmic solution
  2. Alternative solution with new discussion phase
  3. No standardization of ragequit proposals.

As for other alternatives, the original discussion can be found in a link under. However the authors want to emphasize that we believe the current proposal is the most fair and best solution. Original discussion: Standardize ragequit proposals and make it a feature and not a bug - #27 by lyule67

2 Likes

Absolutely support this proposal. Ragequits should always be an option, especially when you have locks up to 3 years where yield situations change drastically.

Sounds overly confusing.
Just do a fee = base_fee + linear_decreasing_fee

Edit: I also like Sam’s idea on selling to protocol in exchange for FXBs. In that route the fees could be smaller (if not free?) because the protocol gets to hold value in the fxb and make revenue that way

Edit 2: may need some fee still tho or else everyone should just max lock I believe? Need to think of game theory a bit but I like the direction a lot.

1 Like

Proposal update. This proposal is on hold until Sam finishes his idea and proposal to have a migration via FXBs which will create a win/win scenario for everyone if possible.

I think converting the unlock into FXBs sounds good as they usually have a market to exit in, so people can swap it out and go into other pools, but it has to be taken into account that this already will give a deduction in the funds due to the dept of those markets and that the peg they currently hold will also be affected (and so current FXB holders are affected)

I take it these proposals are also considering the current pools and not just new ones from here on?

As the current holders of the usdc v3 pool want a resolution as well (it being 0.1% apr)

so it would be bad if theres a 20% ragequit fee and then sit in a 5year lock up fxb that trades below peg and has a 10-20% slipage

When it comes to the proposal to convert unlocks into FXBs I cannot comment. We have to wait for the proposal to be posted from Sam.

Can you elaborate on why this seems overly confusing?

I think the use of variables rather than hard-code might make it a little more difficult to digest

But its really not that complicated if you take the time to chew through it

In short, it applies a variable fee based on the rewards received per each position and offers a fee deduction based on the amount of veFXS locked and the amount of time that veFXS has been locked.

It also ensures the unlocks do not drop CR below a certain threshold, ae if your unlock would drop CR below the threshold it wouldn’t be allowed.

Please find Frax Core Team proposal here: [FIP - 3XX] Locked Liquidity Standard Exit