Simplified Pricing

As indicated in other threads we’re looking to simplify the pricing framework materially. The high level objectives are:

  1. Simplicity - bare minimum number of factors, that pushes complexity off-chain to risk assessors (to come up with complex risk models as they wish)
  2. Decentralisation - simple enough, and only reliant on on-chain info so it can be run entirely on-chain (vs current off-chain quote engine)
  3. Flexible - ability to price not only smart contract cover but any type of risk, so we can roll-out new products quickly

Also, the pricing mechanic has to solve two problems:

  1. Price the Risk
  2. Determine how much capacity to offer on the risk

Proposed New Pricing Mechanic

Price

Risk Cost = High Risk Cost Limit x [ 1 – (Staked NXM / Staked NXM Limit)^(1/7)]

Subject to a minimum = Low Risk Cost Limit

Where;

High Risk Cost Limit = 100%

Low Risk Cost Limit = 1%

Staked NXM Limit = 100,000

The surplus margin of 30% is then added to the cover cost, so the minimum cover cost remains at 1.3% pa

The 1/7 exponent gives the curve its shape. The curve is designed to reduce price quickly for the initial NXM being staked but then become less sensitive when large amounts are staked. After more testing we believe this is better than a simple linear approach, because:

  • Initial stakes are most applicable to new protocols where we want to know is this super high risk, or very risky or just pretty high. Pricing is much rougher here so higher sensitivity is more likely to give us a better answer.
  • Later stakes are more applicable to established protocols where the goal is to distinguish pricing at a more accurate level, therefore we’re more likely to get a better answer with lower price sensitivity the higher the stakes. eg is Compound more secure than MakerDAO, if so by how much?

Visually it looks like this:

Capacity

When someone stakes the capacity will be equal to the value of the staked NXM initially. Then over time the mutual will release more capacity up to a limit, where the limit is a maximum multiple of stake, eg 4x.

If a stake is withdrawn all capacity is immediately withdrawn. This allows the mutual to quickly respond to changes in risk, as if stakers withdraw, price should increase and capacity should be taken away.

So new stakes add capacity slowly over time and stake withdrawals take capacity away immediately.

Conceptually it looks something like this (block-time on the x-axis):

Staking amounts and withdrawals are given by the dotted line, and this is simply one example. After an amount is staked, capacity starts at the staked amount and then increases slowly over time until it reaches a maximum. If staking is withdrawn capacity is immediately withdrawn to quickly respond to changes in perceived risk levels.

Initial factors are open for debate:

Time to reach max capacity = 90 to 270 days
Our view of an appropriate range, but a single value needs to be chosen. 90 days is shown in the graphic for illustration purposes.

Multiple of Staked Capacity = +300%

This means the mutual will offer at most 4 NXM worth of capacity for every 1 NXM staked (once the max capacity time period has been reached).

Decentralisation
We will initially implement the revised pricing by changing the existing off-chain quote engine. Once we have some more experience/feedback and are comfortable with the set-up we will move this on-chain. At this point, quotes and cover purchases to be solely made via smart contract calls.

Specific Feedback Requests:
We’d like feedback on all/any aspect of this proposal but we do have a few parameters we’d like specific input on:

  1. Low Risk Cost Limit of 100,000 NXM (amount of stake required to reach min price). Too high? Too low? Note that stakes can be re-used up to 10x in pooled staking, so stake should be easier to come by, and the higher this number the more conservative (and differentiated) the pricing.
  2. Ramp up period for capacity. On balance we think 180 days is about right but very open to feedback here.
  3. Maximum cover period of 1 year (not listed above). To ensure stake is available for a reasonable portion of the cover we’re suggesting a max cover period of 1 year. Nearly all covers currently written are less than 1 year.
5 Likes

Another consideration: when a contract holds little funds, the risk of getting hacked is lower. Once a lot of money is held by a contract, the honey pot goes up as well as the efforts going into finding exploits, and the likelihood of a hack is increased.

Therefore the cost of insurance should somehow consider the value held in a contract?

1 Like

Therefore the cost of insurance should somehow consider the value held in a contract?

This was specifically in the previous algorithm. Unfortunately it has some technical shortcomings on the implementation side. It depends on the particular system being covered as to where the value is being held and in what form (ETH, tokens etc). Therefore calculating value in each contract even though it’s on-chain is actually quite a challenge in itself, and to be entirely consistent would have to individually set-up for each contract.

Instead, the new method proposes that Risk Assessors perform this analysis themselves and treat value locked as one element influencing how much they will stake. If they see lots of value locked, they stake more.

Maybe this question is more related to pooled staking, but what happens once the staked NXM limit is reached? No more staking towards that smart contract possible?

I actually think this is too low. This would currently represent 2.3% of the total supply. While Paraswap is currently the only contract that has this much stake, I think its fair to assume that with pooled staking more projects will reach this limit relatively easy. It should be harder to achieve a 1% premium in my opinion - in the offchain world I would imagine it takes insurance decades of data and experience to arrive at such a low premium. Maybe you can shed more light on this with your insurance background. My suggestion would be to increase this limit and therefore the high-risk cost limit to 200k NXM. It should be the exception and not the rule to have this low premium.

I am in favor of 90 days, the shorter the better. What are the arguments to increase this duration?

Also question:
What will happen once capacity falls below the purchased cover?

1 Like

Maybe this question is more related to pooled staking, but what happens once the staked NXM limit is reached? No more staking towards that smart contract possible?

Pricing is at minimum but staking continues past this point, it just means rewards are shared among more stakers.

I actually think Staked NXM Limit is too low.

Thanks for the feedback. This is genuinely quite challenging to set, and I can see it being adjusted after we get some feedback from actual use. There is a material supply/demand element to it and it could be too high or too low. On balance, it seems better to set it slightly too high to begin with. Your argument around historic data and experience makes sense. I’m not against increasing it at all, genuinely after feedback on this.

I am in favor of 90 days, the shorter the better. What are the arguments to increase this duration?

When the max is reached someone can buy cover worth 4x stake for a period of 1 year. If all the stake is immediately withdrawn then the mutual is taking all the risk without any stake for a considerable time, 365 less 90 day unstake lock period. While this can occur regardless of the ramp up period, the shorter the ramp period the less exposed the mutual is likely to be because the staker is potentially exposed to risk well before a large cover can be bought. In summary, a longer period reduces the chance of a long range type attack.

What will happen once capacity falls below the purchased cover?

Existing cover remains until it expires but no new cover can be bought.

1 Like

We’ve done some further work and thinking on this.

The ramp-up process for setting the capacity limit is somewhat technically challenging to implement, it can be done, it will just take more time to work out the optimal solution. However, we’d like to get the new pricing out soon as not only does it simplify things it allows other items on our roadmap to progress.

So we’d like to propose the following:

  1. Don’t have any ramp-up factor on capacity to begin with.
  2. Change the Low Cost Risk Limit to 200,000 NXM

Capacity on any system will therefore equal staking amount. So it can still ramp up quickly with stake. This is more conservative to start with but can still scale quickly, which is most likely a good place to be.

Increasing the Low Risk Cost Limit is also more conservative but it provides a greater incentive for stakers to get involved, which we anticipate will actually help capacity grow. It is entirely possible we don’t need the ramp-up period at all and can instead rely on the Pooled Staking leverage factor of 10x to obtain capital efficiency.

In summary, this is simpler and easy to ship quickly. It will enable us to learn how the new pricing behaves and inform any adjustments from there.

4 Likes

I agree. In the future we could consider for longer term, but considering that almost all the projects have a couple of months old or only a few older than 12m it is very reasonable. I think this could also benefits to people to buy cover. Some coverage that today is to expensive could be much lower in the future.