Supply / Demand Based Pricing

Following on from previous discussions on this topic we’ve been working on some draft functions.

Risk Cost = f(1) x f(2) x f(3)

Function Description
f(1) Raw Risk Cost, pricing is determined by how much is staked. Formula has been altered from current to avoid the use of min/max.
f(2) Supply/Demand factor, determines how much pricing load or discount should be applied based on the ratio of Stake to Active Cover
f(3) Surge Pricing factor, determines the pricing loading required when Active Cover amounts get close to the Global Capacity Limit

Previous discussions have focused on the surge pricing factor which increases rates if global capacity is nearly used up. I believe we should also have a supply/demand factor which keeps rates stable within a range but then either loads or discounts rates based on the ratio of staking to active cover, this should help cope with market conditions more dynamically and reduce reliance on governance.

Some draft functions and graphs are included here: https://docs.google.com/spreadsheets/d/1Tl9IyElF3qMoYYFdGjDfHtgLLOTc54lmoAVqg9QTRGQ/edit?usp=sharing
Feel free to copy and play around with the factors to see how the curves move.

Uses price at max stake as an example (meaning f(1) is fixed in the graph). When a risk is heavily staked there is a 50% discount. When a risk is under staked the price increases up to nearly double.

Similar to @Drazav suggestions from a while ago. Small loadings from 50% up to 75% of capacity used increasing to 2x price at max capacity

We can tweak shapes on these curves, so any feedback on these aspects is appreciated.

4 Likes

Will look into it v closely tonight. Until that… some thoughts of the top of my head.

  1. it’s not optimal to have the risk cost reach minimum price at the same amount of min staked (100,000 NXM at the moment) on all the contacts. In other words, different contracts should have different amounts needed to be staked to reach min risk cost. For example, a contract of a big, established lending protocol like Compound should have a higher staked amount needed to reach the staked_risk_cost_low target. Other, lesser known, and immature protocols should have a lower amount needed (with corresponding lower capacities).
  2. the increasing in risk cost surge factor should be setup in such a way that there will almost always be capacity available on needed contracts (but at a discouraging price), allowing people who really want cover for a specific risk to behave similar to playing in a dutch auction… where the price starts high and if you wait long enough, it can drop to the wanted level if no one bids till that point.
  3. the lowest absolute price level a contract would be allowed to reach should be different on different contacts, and not the same on all, as it is now.
  4. with all the factors taken into consideration (the min total stake , the staked_risk_cost_low, the surge factor, etc), the gears should be tweaked in such a way that there should be a decent amount of cover purchased on each individual contract. In other words, the capacity at one moment in time on any given contract should not be very much higher than the amount of cover purchased at that given time. This will be an indication of an effective management of the mutual.
1 Like

@8fold - thanks for the comments!

If you have different pricing curves for different covers how do you decide which products get which curve? This implies active governance and we’re trying to minimise governance and let the market decide rates. So I disagree on points 1 and 3.

re point 2 - this is the goal, the question is whether the proposed shape is correct, level and shape. There is an argument to make f(3) steeper and get higher pricing loading than 2x.

re point 4 - agree, I’ve targeted a ratio of Stake to Active Cover of 150%, as we do want to target some level of buffer. When we get to Staking 3.0 users will be able to remove stake at anytime provided this ratio is above 100%, so we want to target something above 100% in the stable state. Is 150% ok, should it be higher or lower?

Ok. Played around with it for a few hours now.

So far, it seems to me that on f(2), 150% is a good balanced center, though when stake/active cover is 100%, I’d increase the load a bit to 200%, from the current 185.91%. This would better incentivise the stakers, and disincentivise takers, so that there is at least some cover available when net stake is lowish. Though I have to admit, it’s not much of a difference.
I’d go even lower with max discount, from current 50%… provided the overall risk cost doesn’t go below 1% in value.

Regarding surge pricing f(3), it’s ok as it is if it goes implemented along with f(2). If we only integrate f(3) for the time being, I’d increase the max load to 300%, at least. The curve is steep enough imo, and it’s an ok point to start from 50% or 60%.

1 Like

@Hugh So what’s the way forward?

Coming back on this. We’re investigating another option that is simpler and more flexible, getting to the bottom of the pros/cons.

1 Like

I’m eager to hear on this other option! Do share please!

As background, the current pricing approach is relatively restrictive on the option space when considering various combinations of Price and Capacity for a given stake.

It gives one line, based on the staked value, and you can only ever be on that line. It’s quite structured as you can’t access low price/low capacity or high price/high capacity

image

The proposed supply/demand approach gives a greater options space, allowing price and capacity to vary between the light green lines (average in the middle). But it is still quite restrictive.

image

An alternative option is to allow each staker to choose wether their stake reduces price or not (it would always increase capacity). That way we let the market decide based on individual decisions of stakers and we can access virtually all of the option space in the above diagrams.

NB: we would need to drop low-risk cost limit significantly from 100,000 NXM to something like 20,000.

This has the following main benefits:

  • increases flexibility of the pricing, wider option space

  • no complex curves

  • allows businesses that may wish to build on Nexus in the future to buy NXM and fully control prices themselves for their niche business line (think of a specialist broker)

  • Allows new cover markets to be bootstrapped a lot more easily (lower risk cost limit) and helps with diversification.

Downsides

  • more complex for stakers to make decisions

  • could argue we don’t have enough experts/liquidity at this stage to get fully informed results and we’re splitting it further to get more signal, therefore a more structured approach is better.

You talked about this approach with “choosing whether your stake would move pricing or not” before. I’ve argued then that most stakers are not qualified enough as to “correctly” asses the right answer. I still keep my opinion. Most stakers are not cabable / sufficiently interested to make such decisions.

What seems clear to me is the need of:

  1. effective pricing based on Stake vs active cover (aka Supply/Demand factor) - increase pricing on low stake/cover to incentivise staking and decrease pricing on high staking vs cover to incentivise buying cover.
  2. surge pricing when demand reaches global capacity (remember when SAFE happened, we instinctively increased the effective price from 1.3 to 5.2%) - easy to implement.

At least 2) should not be voted independently, as you propose in the last reply. When covers bought is v close to max capacity, the mutual should absolutely react. In my opinion, that is not debatable.

I’d be happy if others would chime in as well…

On item #1 we have a choice between a) supply/demand curve and b) stakers choosing.

On item #2 we should implement the surge pricing regardless and this should not be linked to stakers choosing, totally agree. I wasn’t clear on that point.

On #1 As you mention there are pros/cons with both. I’m strongly of the opinion that more flexibility is needed longer term, but can see arguments as to why more structure may be beneficial now. I’m thinking we can guide this in the UI and get the best of both worlds, but haven’t got a fixed view on it as yet.

1 Like

I was actually visualizing something quite similar myself :slight_smile:
Perhaps in the form of a visual recomandation (as in manually gearbox, more modern car, where it “suggests” up-shifting, but does not shift itself. Or … i don’t know. But I’m glad we got the same idea.

1 Like