Ragequit and Ragequit Lending

This post outlines the design for the ragequit feature and introduces a new component called ragequit lending.

Benefits of the ragequit feature are:

  • Creates a price floor for YAM based on book value
  • Provides liquidity for holders who choose to exit the YAM ecosystem when market value is not favorable

And additional benefits of implementing the lending component can be summarized as:

  • Enables more productive use of funds that are allocated to the ragequit pool

  • Enables self-sustaining growth for the ragequit pool

  • Provides access to ragequit value for holders

Functions

The ragequit feature will consist of three functions:

  1. Ragequit - allows user to redeem the maximum amount of value available in the ragequit pool for use in ragequitting
  2. Simple Borrow - allows user to borrow funds from the ragequit pool
  3. YAM Long - allows user to borrow funds from the ragequit pool and automatically purchase YAM

Ragequit Pool

The ragequit pool is the pool of funds used by each function. The pool will be seeded by the treasury. Fees accrued by the lending functions will be distributed among the three functions. The ragequit pool may require periodic replenishment, either by automatically distributing a percentage of treasury profits to the pool or via governance as needed.

YAM Pool

The YAM pool is the pool that holds the YAM that is transferred into YAM Finance custody upon ragequit or liquidation of a loan. YAM Finance can then decide how to best use each YAM, i.e. burning, replenishing ragequit pool, using for incentives, providing liquidity, lending, etc.

Ragequit

This function is used to fully exit the YAM ecosystem with the maximum amount of value that the ragequit pool has available at the time of the exit.

Transaction execution would flow as follows:

  • Transfer funds from the ragequit pool to the user
  • Transfer YAM from the user to the YAM pool

Simple Borrow

This function is used to borrow funds from the ragequit pool. YAM is deposited and locked as collateral, while a portion of ragequit value is transferred to the borrower. The loan will incur interest that must be paid along with repayment of the borrowed amount before reclaiming the collateral. If the collateralization ratio falls below a certain threshold the loan will be liquidated and the YAM will be transferred to the YAM pool.

Transaction execution would flow as follows:

  • Deposit YAM into the contract
  • Transfer funds from the ragequit pool to the borrower
  • Begin n% interest rate
  • Upon closing the loan:
    • If user initiated, transfer repaid funds and paid interest to the ragequit pool and release YAM to the borrower
    • If liquidation, transfer n% to the liquidator and the remaining YAM to the YAM pool

YAM Long

This function uses the simple borrow function to create a YAM long by automatically borrowing funds and purchasing YAM for the borrower. The newly purchased YAM is then locked with the collateralized YAM. The loan will incur interest that must be paid along with repayment of the borrowed amount before reclaiming the collateral. In addition, when closing the loan if the long is profitable a closing fee will be incurred. If the collateralization ratio falls below a certain threshold the loan will be liquidated and the YAM will be transferred to the YAM pool. The interest rate for this function will normally be very low (further explanation below).

Transaction execution would flow as follows:

  • Deposit YAM into the contract
  • Borrow funds from the ragequit pool
  • Buy YAM
  • Deposit YAM
  • Begin n% interest rate
  • Upon closing the loan:
    • If user initiated, transfer repaid funds, paid interest and closing fee (when applicable) to the ragequit pool and release the YAM to the borrower
    • If liquidation, transfer n% to the liquidator and the remaining YAM to the YAM pool

Interest Rates

Interest rates will be set according to a bonding curve. As the utilization rate of the ragequit pool increases, interest rates will increase up to some maximum utilization rate beyond which interest rates spike dramatically. The remaining funds in the pool are reserved for ragequit. This enables the maximum amount of funds in the ragequit pool to be used productively in lending, while simultaneously being made available programmatically for the ragequit function.

Liquidations

Liquidations will be performed by individuals using an open source liquidation bot that will be made available to the community. Some portion of the liquidated YAM will be given to the liquidator as payment for services and the remaining amount will be transferred to the YAM pool.

Additional Funding

Because the ragequit pool will only be a portion of the treasury, in the event of a mass exit not all holders will be able to use the ragequit function. To mitigate this the ragequit feature may utilize some fundraising mechanism to provide additional funding for the ragequit pool. Currently there are two ideas for this:

  1. Discount Sell and Lock - When the ragequit pool is sufficiently depleted YAM from the YAM pool are sold at a discount and locked for a period of time. The proceeds are used to replenish the ragequit pool.

    Example: YAM’s market value is 90% below book value. An arbitrageur purchases market value up to 95% and uses ragequit bringing book value down to 95%. The ragequit pool sells the YAM at 94% below book value. The YAM are locked and proceeds are returned to the ragequit pool resulting in 94% of funds being replenished.

  2. Bond - funding would be secured by issuing a bond to ragequitters that would be repaid by the treasury at a later date. https://forum.yam.finance/t/yip-add-ragequit-functionality/588/5

5 Likes

@TOTv3 I like this idea and have thoughts on the mechanism to determine interest rates, which is pretty undefined in your post. The goal is to use the interest rates to throttle the demand so that borrowing does not use up all of the lending pool.

System Parameters:

YAM (YTotal) : total supply of YAM BoU Is this known?

Lending Pool Total (LPtotal): $ Amount borrowed and unborrowed in Lending Pool

Total Borrowed (LPborrowed): $ Amount borrowed from Lending Pool

System Utilization: LPBorrowed/ LPtotal

Base Rate = f(System Utilization) where the function is a curve that generally increases as utilization increases. Below is just for illustration purposes. The curve could be more flat and kinked like the Compound utilization curves. A more continuous curve seems more fair, although maybe less efficient.

Borrower Parameters

Yam Collateral (Ydeposited) = YAM collateral deposited into Lending Pool

Ragequit Share (RQ) = (Ydeposited / YTotal) * LPtotal

Borrow Amount (BA) = Amount to be borrowed against Ydeposited Max can be limited by a collateralization ratio.

Surplus Ratio (SR) = (BA / RQ) - 0.95

Variable Individual Rate = Base Rate * SR

The individual rate is a function of the total utilization of the lending pool as well as the amount above the ragequit share(RQ) that the borrower is entitled to. Borrowers can borrow up to a determined C-ratio by depositing their YAM. When borrowing above the RQ the loan is subject to liquidation if the principal plus accrued interest crosses the C-Ratio. A portion of the YAM equal to the RQ is sent to the ragequit auction.

Ragequitting

The option where a user can choose to explicitly ragequit is a good idea. It means we can take control of those YAMs directly and liquidate them. These could be burned, held in the treasury, given back to yield farmers, or sold. My first thought is a combination of incentive rewards and below market auctions to existing YAM holders would be a good use of them. Selling them cheap to existing holders would replenish the treasury and provide a bonus to existing YAM holders.

Issues/Questions

One UX issue is how to differentiate between someone who is rage-quitting and someone who is just borrowing the same amount. The solution that I am proposing here is to set the last variable in the Surplus Ratio to less than 1 (Surplus Ratio (SR) = (BA / RQ) - 0.95). If you set this to 1 then anyone borrowing just the ragequit share will pay no interest since the equation will equal 0. By setting it to 0.95 then the interest rate will be Base Rate * 0.05, which should be very low when the base rate is low, and scale higher as it increases. This needs further exploration.

Many of these types of loans could eat up the lending pool liquidity and raise interest rates for other borrowers if this rate isn’t calibrated. I think we should think of this as “this ragequit share is your money, so you can borrow cheaply with it.” But if it is free why would anyone ragequit? We don’t want to have half our treasury locked up without getting much benefit from it.

The Base Rate Curve needs modelling and thought around the shape and how we want this to work. There is a trade-off between “fairness” and efficiency.

6 Likes

The bonding curve for my design will do this as well. (Credit @trente for pointing me to the right kind of curve). It will also programmatically allow funds to be used for lending or ragequitting as needed. You can think of the curve as being almost flat with just a slight upward slope as it moves from the left. Then as it approaches the right end there is a dramatic spike upwards. Depending on the percentage values we end up choosing, this would put a cap of lending say at 90% of ragequit pool, while 10% is reserved for ragequit.

Yep, same idea.

Can you give some examples here to better help me understand and get us on the same page more quickly?

Yep, see the YAM pool section. Thanks for your help (as well as @Skelectric and others) in this design direction.

Yeah, in the Additional Funding section I outlined something like this called Discount Sell and Lock. Do you have any thoughts on that?

This is solved by having a separate ragequit function.

I am interested in this, but like I said above, I haven’t quite digested it yet. It may be a better solution, if you can help me to understand more quickly, I could tell you why I think it is/isn’t. Some examples/scenarios would probably help. In the meantime, I’ll continue chewing on it. Thanks Ross.

1 Like

For the sake of shipping quickly, and related to some concerns around treasury assets and liquidity, I’m wondering if this should be a V2 feature? The simple borrow would allow people to manually lever up, and if someone wanted to build a proxy leverage contract we could implement that, but it might increase complexity and introduce a bunch of edge cases to build this in on day 1.

3 Likes

Yeah, I see no issue with that.

1 Like

loving the idea of an interest rate bonding curve to discourage too much of the pool to be lent out

when ragequit is called - how would we factor in the lent out portion of the pool? what if there are not enough liquidity to “RageQuit en masse” due to Simple Borrow?

1 Like

Good question. So, as funds available for ragequit are depleted the bonding curve shifts forcing interest rates up compelling people to close their loans which automatically frees up funds for ragequitting.

Before Ross takes any more initiative to draft the borrowing logic, I want to highlight a potential decision point we have to make first. Do we want (1) the lending pool be the entire treasury and just cap lending pool at X%, or (2) the lending pool to be X% of the entire treasury?

Option 1 allows for only a subset of users to leverage their YAM’s ragequit value (pro-rata allocation to the treasury, and results in high utility for fewer users.

Option 2 allows for all users to leverage their YAM’s ragequit value, but since its a pro-rata allocation to a subsection of the treasury, the utility to all users suffers.


Also, what’s the rationale behind charging interest for the YAM long? I recall 0% in earlier brainstorming discussions.

1 Like

Yep, this is a design dilemma for sure. Trent’s suggestion was to go option 1 (1:1 ragequit value for borrowing) for MVP, which I tend to agree with. His argument was we don’t know how much use it’ll receive and the bonding curve that addressed this from my original design adds additional complexity that may not be worthwhile for now.

As I’m thinking about this though, I’m thinking there may be a simpler solution that levels the playing field between the two options, which is simply to have the proportional share of ragequittable value/borrowing potential be static, instead of dynamic.

Yeah, when I integrated the ragequit function I realized it was necessary to add an interest rate to ensure that funds for the ragequit function could be freed up from lending by those who didn’t actually want to ragequit. Without that you stand to lose a substantial amount of power of the ragequit feature to create a price floor, which is an important design goal for the community.

I agree that option 1 is most optimal in the beginning while the product’s utility is still in discovery. I would suggest setting X% to a low value (maybe 5% initially, increasing over time) to facilitate testing in prod and as a simple risk management strategy. You could also limit usage to Y yams per wallet, at least in the beginning.

With respect to a simpler solution, not sure what you mean by static/dynamic. The options are already static in the sense that any YAMs a user holds will always have a static pro-rata allocation of whatever is defined as the lending pool, assuming no further transactions by the user or the lending pool(i.e. if user holds 10% of YAM supply, user should be able to retrieve 10% of lending pool).

Also, here’s an idea that addresses both what to do with the liquidated YAM pool and how to enable 0% YAM longs: just link the two concepts. Make it such that YAM longs leverage the natural imbalance that results from liquidated YAMs being in the treasury. The treasury doesn’t “want” those YAMs anyway, right? You’ll have a natural debt ceiling for YAM longs, have a mechanism for disbursing or assigning value to liquidated YAMs at potentially no cost to the treasury, and enable very low cost (0%?) YAM longs.

hmm, so YAM collateral when funds are lent out from the RageQuit Pool don’t count when calculating RageQuit %?

I feel like they should as you still are entitled to % of that pool, no? no matter what the asset it is.

YAM book value should only ever be a function of non-YAM assets held by the treasury to allow for value-capture metrics to actually make sense. If even a fraction of YAM book value is derived by YAMs themselves, that fraction is potentially valueless as a price-floor.

As an analogy: you wouldn’t want your DAI to be backed by DAI now, would you?

First, I wanna point out where I think there might have been a miscommunication. If not, then just let this serve as greater clarification:

My interpretation of each option was:

  1. Each YAM can be used to borrow 100% of it’s respective amount of book value and the number of YAM of the total supply that can do this is limited to the size of the ragequit pool, but almost the entire (capped by interest rate) pool can be used for lending.
  2. Each YAM can be used to borrow only a portion of it’s respective amount of book value and the number of YAM of the total supply that can do this is greater than option 1, but still limited to the size of the ragequit pool. The pool will never be at max capacity because all YAM will never be used for borrowing.

My initial design uses a bonding curve, where as utilization rate increases each YAM’s (in subsequent loans) access to it’s respective amount of book value increases. I believe something like this is the best balance between the two options because it increases fairness in access to funds for lending in the ragequit pool, while also allowing the maximum amount of funds to be used . In this way it is dynamic.

The two options you have listed are static. Viewed in this way (without the bonding curve) the playing field is leveled between the design choices with respect to an MVP. So, for me that means taking another look at the tradeoffs between the two options.

Can you elaborate here?

Would need a numerical example to demonstrate how you think this should work. My impression is that this introduces needless complexity for an MVP.

Also it doesn’t make sense for access to book value to increase as utilization rate increases, the incentives would result in initial users holding-off on using the product at all, and latter users to FOMO in and use up the entire treasury. A decreasing function makes more sense, i.e. users progressively get less book value for their YAM collateral as treasury gets used up. But again, implementing such a bonding curve may be best left for a latter iteration of this system.

Let’s say as of time 0, liquidated YAM pool = 0 since no YAMs have been liquidated to date. As time progresses and users’ YAM collateral gets liquidated from rage-quitting and exiting the ecosystem, liquidated YAM pool grows. Currently, this pool of liquidated YAMs doesn’t serve a purpose, but i’m theorizing that it could be leveraged for the YAM long functionality as some sort of pseudo-liquidity pool of highest priority, or as the only liquidity pool serving YAM longs, where the liquidated YAM supply serves as a ceiling for how much YAM-longing can be used.

I see, sorry, I missed that question in your first comment.

So, let me make sure I’m getting your question right. You are asking if the YAM used as collateral in a loan will be reflected in a book value calculation?

Yeah, this is the current conclusion.

That is the idea.

Yes, but replace treasury with ragequit pool. We want the ragequit pool to be fully utilized (up to some portion set aside for ragequit by interest rate) so that funds are not sitting idle and unproductive.

Yeah, I mean this would have a similar outcome. A major difference is as each YAM’s access to book value decreases users become less interested in fully utilizing funds. Whereas with an increasing function, once the initial hump is overcome, utilization rate will be more likely to reach full capacity (also depends on interest rate).

Yes, that is why I said:

This is interesting and could be a use for the YAM pool. At the moment though, I like the idea of keeping it’s use open ended:

There’s little chance of outcomes being the same here, and why is maximizing the utilization rate a goal of the product? With that sort of structure, rather than rewarding early users for basically beta-testing your product and generating data for further improvements, you’re arbitrarily making an initial hump before which using the product has less utility.

Why gimp the product in the early stages? It doesn’t make sense to me. The most powerful motivators are the ones that make people money, and I fear that disincentivizing early use of the product through lower utility could have some undesirable consequences. It would cause something like anti-FOMO, like Fear of Getting In (FOGI lol). Anyway, seems like this is mostly a talk for another time, but I just wanted to point it out.

Yeah I definitely saw that, but there’s also no harm in coming up with a use for it now either, especially if it ties up a loose end. For all we know, an implementation including a use for the liquidated YAM pool could end up being dead-simple. Just a matter of continuing to brainstorming actionable ideas: eventually somebody will come up with one that’s strikingly elegant…