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:
- Yes to algorithmic solution
- Alternative solution with new discussion phase
- 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