I’d like to start brainstorming some more long term cover premium ideas that is a bit more dynamic so that we don’t require a governance change whenever we get these weird bursts of cover demand and have to quickly adapt.
This is a ‘part 2’ plan to the current cover premium change, aimed to be a post-farming madness change when we ‘revert back to a norm’
Currently price is determined based on Net Staked NXM only:
This helps the price move up and down the curve based on staked NXM and therefore determined risk by the community.
However there is no where to factor in cover demand/remaining capacity. I believe that available cover capacity remaining should also drive the price modifier slightly, but to nowhere near the extent that the NXM stake does.
I’ve put together a quick chart to demonstrate a potential idea.
In this example I’ve used the 1.3% cover premium floor as an example because it’s a number we are used to. I still think that this can still remain the floor but by just adding a adjustment based on capacity we can ramp up the price once cover demand starts nearing supply exhaustion.
In this example for a contract that already has maximum net stake such as Yearn, Curve, Synthetix etc - a 1.3% floor would be in effect due to the Net NXM Stake original curve.
Based on my curve calculation (I went with an exponential growth of ^1/77) this would mean that the first 60% of available cover is still priced at 1.3% so no change.
However once remaining cover hits 40% the price starts increasing on the curve.
As highlighted example shows, 10% cover remaining would take the price to 3.2% and then aggressively move up to 6.4% across the last of the cover availability is dried up.
That means during times of farming demand like now - the amount of available cover currently never really dips below 5-10%. So prices right now for cover on the maximum staked protocols would be around 3.2-6.4% instead of the 1.3% it is currently.
Realistically we don’t actually want/expect to have cover usage under 50% so the true range of prices for the common protocols would be likely around 1.3% and 3.2% on average so this is still an average increase in premiums based on pre-farming usage - but not a big uplift overall.
The curve can be tweaked to be more or less aggressive, here is a curve of ^1/140 for example:
I feel a bit silly quoting myself but this point has already become more relevant only hours after I made the post.
People are currently doing a mass-exodus from $SAFE and the ship is being abandoned, yet our pricing proposal hasn’t even finished governance voting yet. By the time it passes the farming bots will most likely have stopped.
This is why I think having dynamic conditions as much as possible is critical - need to cater for as many of the ‘what-if’ scenarios in at the protocol level as possible - not the governance level.
Granted, this particular situation is pretty hard to predict so I’m not sure we could have done any different, however I just wanted to re-iterate my dynamic/adaptive messaging that you may have noticed from me across a few of the previous changes (MCR rates, Cover etc)
Thanks for contribution, @Drazav. I agree with a dynamic adjustment of cover prices. This can be done using multiple parameters, one of which you proposed (demand).
Aave protocol uses a similar approach for borrowing rates. The less tokens available for lending, the higher the borrowing rate. Though in our case, the exact points where the curve changes can and should be discussed (the point at 40% remaining, in your example), along with the price curve.
One other such factor can be time. The more time that passes without a hack/valid claim on a contract, the cheaper cover for it can become. In our case, the cover_pricing_floor This needs a little brainstorming as well.
One thing that I am clear on right now is the 1% stacked_risk_cost_low parameter (and 1.3% price) is too low. This is mainly because I don’t know where than number came from. Given the smart contract risk in general, at this moment, I believe this to be inappropriate (doesn’t sufficiently compensate for the risk).
Thanks @Drazav for the insightful contribution. I generally agree with the high level intention of making price dynamic so we are not always caught reacting to events with a 3+ days lag (years in crypto time…). Also it sounds right that stakers get rewarded more the less available cover there is (they are taking more risk in aggregate).
Your proposal looks in some ways akin to Compound interest rate being set depending on utilization rate, and it feels like the right direction of travel for Nexus too.
The question I have is whether this incentivize the behaviour we actually want (i.e. more capacity becoming available through more staking):
Contract maxed out > more staking > more capacity > additional demand met
By making the pricing increase as utilization goes up, we might slow down the pace at which we max out on certain contracts, perhaps resulting in a slow down of more staking becoming available.
The other question I have is how staking would affect your pricing curve: let’s say we are at the 40% threshold and the next cover goes up in pricing, then more staking comes and we go down below the threshold, so the next cover is back at 1.3%. Or the other way around if someone unstakes. These movements are not really demand driven, more supply drive rather.
Just sharing some thoughts, as I mentioned I think the direction of thinking is the right one.
Time was actually a factor in the initial pricing algorithm that just got changed a few months ago. I recommend everyone to read this post: Demand Adjusted Cover Premiums
In general, I agree with Drazav’s suggestions. It also creates a nice incentive for cover purchasers to be early. I prefer the curve in example #2 more, as we leave more room for cover purchasers, which are usually quite price sensitive. There was this time right after the new adjusted cover algorithm was implemented where the staking requirement for the minimum price was quite high and barely any cover was purchased.
I question this incentive. Ideally we want users to buy cover when they actually need it (ie when they start being exposed to the risk), not ‘early’ or ‘late’ because of pricing. And when they need it, we want cover to be available. Incentivizing early cover also would put at disadvantage users that need cover for shorter durations.
I really like the idea, we need to move to a more market driven approach. A couple of points:
We should probably only have the higher pricing trigger in relation to the global capacity limit (20% of MCR), rather than the specific risk staking capacity (staking based limit).
We want a generalised pricing algorithm, that works for any risk, so keeping time out would be beneficial @8fold
there is a higher level benefit here that the approach discourages concentration of risk (and therefore encourages diversification) which is strategically beneficial to the mutual.
this doesn’t shift us to a market approach for the min price at lower capacity levels, eg 1.3% is probably still too low and it’s a governance factor.
Another option which could be implemented in conjunction or instead is to allow stakers to choose whether their stake on a contract reduces price or not. So they would still be eligible for rewards/punishments but they can choose to add stake without reducing price.
This would allow the aggregate of individual stakers to effectively set price and would mean you can have high staking and a higher price. This would give us a market based approach to the minimum price (before demand is high) as well. Downside is that it will take longer to implement as it requires smart contract changes. Whereas we can do your suggestions relatively quickly as pricing is off-chain for now.
I’m actually in favour of doing both. Yours now and adding in this staking choice element later.
If we have both of these then governance shouldn’t be required to respond to market movements which is where we want to be.
Agree with that. Makes sense that the higher pricing curve is not triggered at least until low_risk_cost_limit (currently of 100,000 NXM) is reached. And then activate curve in relation to the 20% of MCR limit.
How would you see this implemented? Would the Risk Cost based on the value staked still be in place? If so, would the option to reduce price or not become available after low_risk_cost_limit is reached (as in meeting an initial pricefloor). In general, I don’t think the bulk of stakers are capable of efficiently assessing whether the cover price is too high or not. I think we should discuss and vote for an algorithm to price covers based on curves and (polynomial) functions.
Agree with this.
Overall, what I see as a quick(er) response to this situation would be use the Risk Cost based on the value staked as initial price-drop mechanism, followed by a pre-decided staked_risk_cost_low (of 2 or 3%, subject to another vote), followed by the triggering of a curve that raises the price once we approach the global capacity limit per contract.
Right now staking reduces price AND increases capacity. Ideally we want to be able to separate those two items, so my idea was to allow stakers to choose wether their stake reduces prices or not (it would always increase capacity). However, in general the idea of pricing curves makes a lot of sense. Will start exploring this a bit more.
Whatever the solution is it’s very likely supplementary to the original post which we should probably implement anyway.
Agreed, I did take that into account and when pricing is already higher due to net staked NXM it the demand adjustment doesn’t kick in until very late or not at all.
Example: 85k NXM using curve 2 doesn’t affect the price until 95% usage
As you can see the demand curve now has no impact and price is 100% driven by Net Stake until the contract gets closer to the global capacity limit
Yes perhaps 1.3% as the min is still too low but we also want to encourage buying up cover when not much cover is active. Perhaps something such as 2% as min low risk cost to set the floor and then staking curve + demand curve to make up the rest of the calculations.
Realistically any protocol with enough demand to attract 100k+ NXM stake is probably already going to be attracting cover purchases enough that it’s rarely sitting at the minimum anyway due to demand.
So I believe the min cost won’t actually factor in that much anymore.
I like the idea in principle however I do get a bit cautious with anything that introduces choice and affects pricing as if there is even a slight chance of gaining a 0.000001% edge by manipulating it, you can bet that the market will do it.
I think most likely the 100k NXM staking limit also needs some sort of curve so it can grow/shrink as it needs to.
