This is a response to this post in discord by @designer
Interesting turn of events over at Unslashed Finance: putting up a vote to halt selling insurance or continue to allow withdrawal out of their Spartan Bucket. Read more in their Discord here: Discord and the forum post: https://forum.unslashed.finance/t/capital-withdrawals-and-direction-for-the-next-weeks-months/159Essentially a miscalculation in the power of a 20% deposit APR for retaining depositors. Many are seeking higher yield elsewhere evidentlyAnd without those deposits, they can’t sell more insurance. They are now considering an exponential increase to insurance premiums as the existing capital gets used up.
I read through this discussion and some of the tangential discussions about it. Here are my takeaways:
First, I will do my best to summarize the issue that they had. Umbrella and Unslashed seem to have pretty similar structures. It is hard to say exactly how theirs works as I have not found a ton of detailed information. As far as I can tell, the rates that are charged to protection providers are not currently set by market demand, but are subsidized by token rewards. The unslashed team targeted a 20% return on ETH provided for protection. mainly from rewards. As the value of Unslashed’s native token fell, the return for providing liquidity also dropped and many protection providers decided to leave for greener pastures, all at the same time. This caused all of the buffer that allowed withdrawals to be used up and now no one can exit until existing protection expires.
What happened to them is also possible in our model, but the details are impacted by the specific characteristics of our pools, specifically the shape of the utilization curve and the length of coverage that users can buy. understanding how this same scenario could play out in Umbrella is a useful exercise to run through to better understand the parameters we are trying to dial in.
In our model, protection seekers lock in a price for a specific amount of time based on the utilization of the whole metapool. This sets the rate they pay until their coverage period ends, at which point they would need to re-buy protection at a new price (also determined by the utilization curve).
Let’s show this with an example:
If there is 100 ETH worth of protection provided to the pool, and 50 ETH of it is already bought up by other buyers, then if Alice is the next person to buy protection, she will pay a fixed rate based on the current utilization ratio and amount she plans to buy. If she buys 20 ETH worth of protection then she pays a rate that (I think) is calculated based on the area under the curve between 50% and 70% utilization. Once she has purchased her coverage, there is still 30 ETH worth of liquidity available to buy but it is now more expensive for the next buyer.
The price of new coverage bought does not impact protection providers who want to leave. After Alice buys, they have 30 ETH worth of liquidity buffer with which to exit. Bob wants to exit with his 25 ETH that he has invested and uses up all the liquidity by exiting. The utilization rate goes up to 95% and it gets much more expensive for new buyers to come in. This is intentional in that it prevents this extra utilization from getting fully purchased.
Because the rates that protection buyers are paying are fixed at the time they buy, any new protection providers are still making the rate from before Bob left (slightly more since Bob’s share is split between those who are left). So if Charlie deposits 25 ETH after Bob leaves, then he will earn the same interest rate on his funds as Bob did.
But if lots of protection providers are exiting the pool because the rate is too low, then it may not be reasonable to expect new protection providers to enter and fill these positions. This may be the market saying that the risk/reward payoff for this pool is not sufficient to keep protection providers around. Without a way to adjust this risk/reward calculation, there is a risk that this pool could trap some protection providers.
Without new protection providers entering the pool, there may not be any liquidity available to exit until protection buyers’ coverage expires and they choose to leave because new coverage is too expensive. The pool should eventually find an equilibrium, but until it does, this could be an uncomfortable and unexpected position for a protection provider to be in.
There are a few ways that we could mitigate these issues. Some of these are possible to achieve while others require code changes and other engineering changes:
- Protection buyers should have a maximum duration for coverage before needing to renew. A longer period is better for buyers but riskier for providers. A shorter period means that the rates a buyer pays will change more often. Something like Unslashed’s epochs could be useful here. (easier)
- We may want to start our MVP pools with pretty steep utilization curves to make sure that there is always a buffer available to exit. This is be less efficient for protection providers, but this may be a tradeoff worth making.
- If Utilization is at, or close to max, is there a way for protection provider withdrawals be added to a queue that gets filled in order whenever the protection IDs are swept? Is there another way that protection providers looking to exit could do so without having to constantly monitor the utilization of the pool?
- Probably a non-starter with the current code base, but having a way to adjust the utilization curve could help. This would allow prices to be raised or lowered to make a pool more attractive to either protection providers or protection seekers.
- subsidizing protection seekers or protection providers could also potentially help, but only in specific conditions. Relying on incentives seems to be what has come back to bite Unslashed, so this should be a secondary mechanism.
- Education will be important for protection providers to understand that there are conditions where they may have to wait to get funds out of a pool.
In conversations about this issue, we have compared these pools to Compound pools, and they do work similarly. There is a chance that liquidity providers in Compound are not able to exit if utilization spikes, but the fact that borrowers are exposed to the utilization rate costs in real time makes the system different. In compound, if utilization spikes, borrowers are incentivized to repay loans because their interest rates will be high. With umbrella, there is no active mechanism to have protection buyers close positions since they are not affected by the utilization rates until they have to re-buy.
An element that would definitely require code changes but could help mitigate this issue would be a secondary variable that adjusts the max payout percentage if utilization gets high. This adds complication, but would provide a lever with which to push protection buyers who have locked in a low price to pay more in a roundabout way. Instead of costing them more, they would receive less coverage as the pool reaches higher utilization. They could then add more coverage at the current rates.
As we move forward with an MVP product, these are issues that we should be mindful of, even if we may not actively implement them right now. I am curious to hear other people’s thoughts on this issue and whether people think it is something to be concerned about or not.
Please chime in here, or feel free to come ask questions in Discord!