Addressing the Negative Feedback Loop

Governance Discussions Nexus Mutual Protocol Improvement Proposals
1

Hi all,

I’ve posted some of these thoughts in Discord over time but thought I’d put them all here for discussion.

Seems like we are stuck in a bit of a rut now, not a lot of new staking coming in because rewards are low and rewards are low because not a lot of cover is being purchased because cover prices are high until there is more net staked.
I think we’ve introduced a negative feedback loop by putting in numbers that are based on future targets rather than scaling to the current situation. For example 200,000 NXM as a 1.3% PA cover cost is fine as a future target but we shouldn’t impact the highly staked contracts right now.

2 things I think we need to address:

1. Fixed numbers do not scale
Choosing a fixed number for things causes unbalanced impact to either the short-term or the long-term depending on what you are trying to achieve. Once we hit the 200k NXM target for cover to cost 1.3% PA, then what? Should the ceiling be raised once a bunch of contracts hit it? When do we decide that?
Why does an arbitrary figure of 200k NXM staked mean the contract is deemed lower risk by members vs total amount staked relative to other contracts/total capital?

Potential solution: Variable targets.
Instead of 200k NXM net staked being the lowest tier cost for cover and adjusting from there it should be a variable target based on either the capital size or the total NXM staked.
We need to auto-scale based on capital and activity in the mutual, no point doing gov proposals to catch up every 3 months causing potential friction if we don’t have to.
Same goes with the MCR re-balance, although this is temporary so might not matter as much but having the ability to ramp up/down the MCR injection depending on MCR% would allow us to burst that capital into the fund when MCR% skyrockets but also return to a steady state once MCR% is lower.

During the craziness of the pump a 1-4hr MCR made sense, now maybe a 12hr makes sense, maybe next week an 8 hour is best suited
Why not treat it like mining difficulty adjustments conceptually? If MCR % is over 200% then MCR is 4 hourly, if MCR% is 180-200% then 8 hourly, if 130-150 then 24 hourly etc etc
Then each day the timer adjusts based on that days MCR %

2. Net Staked NXM
This is a good idea in theory but I don’t think works as well in current format especially due to the speculative nature of most investors.
When a person unstakes for whatever reason, could be they want to re-assess in 90 days, could be they want to re-balance the proportion of stake per contract - this then removes the staking capacity which affects the price of cover. While I agree that unstaked amounts should be taken into consideration, I don’t think the entire stake should disappear from the calculation for cover as soon as the unstaking timer counts down.
If a claim comes in during the 90 day unstake period, then the stake can still be burned - so why treat it like it doesn’t exist as soon as the unstaking timer starts.

Potential Solution: Treat the unstaking process just like we used to in terms of gradual release.
If a person unstakes then that staked amount is slowly removed from the calculation against pricing over the 90 day period.
So let’s say 10000 NXM is unstaked, day 1 the net staked amount might be 9998, day 2 9996 etc until day 90 where it’s 0. The impact to the price formula for cover is then spread across the unstake period and realistically represents risk of staking being available in the event of a claims burn.

Thanks for hearing my 2c!

8 Likes
2

this is the part about the mutual that I love the most. Thank you for pointing out a few areas for improvement and also for bringing in some constructive ideas. This reinforces the very value proposition of being a member, whether we accept this modification or not. Thank you

1 Like
3

I love the idea of “mining difficulty adjustments”. It will reduce unnecessary volatility.
Love the unstaking process stepwise reduction too!

Feel like current situation is like 0 or 1 (for MCR% and the unstaking). The perfect solution is to achieve a balance, and the two proposed solutions are exactly what we need.

4

Thanks @Drazav great to hear your thoughts!

Agree with your assessment of the situation and the need to get back into a positive cycle. I’d also add that more staking is required to open up capacity and lack of capacity is blocking cover purchases on protocols (regardless of price).

I think cover prices were too low previously but without more staking coming in they are likely on the high side right now.

re Fixed numbers - we can’t do a lot here in the short term re structure (it takes time to develop) and generally I think we should get more experience before making larger protocol changes to facilitate something like this. I suggest we should look to adjust parameters we already have for now and use that as experience to develop any variable processes.

On the MCR% increment specifically I actually see this as a short term measure only. We need to get to a position where MCR is being driven by cover purchased rather than these increments (so it does effectively become fully variable at that point anyway). The increments are currently being used to get up to a meaningful level of scale so we can meet demand for larger covers.

But that’s just one example, there are others like the pricing limit that may need a more dynamic approach.

re Net Staked NXM
This seems like quite a reasonable suggestion to me and I’d apply it to both Pricing and Specific Risk Capacity Limit (amount of capacity offered on each contract).

So we can make an informed decision, the downsides are as follows:

  • when something happens that indicates a protocol is a lot less secure than previously thought prices don’t react immediately.
  • encourages stake > immediately unstake pattern a bit more than currently (may need something else here anyway)
  • mutual would end up offering more cover on an un-staked basis as cover can be purchased while stake is disappearing.

The first one is probably the largest downside with the other two being more minor.

Alternative option:
The other combination of changes we could make is decreasing the 200k to a lower level in combination with increasing the specific risk capacity limit from 1x Net Stake to 2x or 3x Net Stake, but with the 2x or 3x likely only for current larger protocols that have been around for some time.

This would decrease prices and open up more capacity quite quickly.

Benefits over run-off approach:

  • technically easier to implement
  • likely a larger/quick change to improve the current situation, especially on capacity.
  • still maintains ability for price to react quickly

Downside vs run-off approach

  • more aggressive re mutual offering cover on an un-staked basis
  • opens up another factor to govern in the future.

(Note: if the 200k pricing limit is decreased then 2x or 3x needs to be introduced otherwise capacity never reaches the global limit of 20% x MCR)

1 Like
5

Thanks @Drazav for kicking off the conversation, a great assessment indeed.

@Hugh thanks for contributing. Can you please remind everyone how the 200k NXM was picked as the right number? I think the key to get out of this loop is to make it more attractive for stakers to stake (right now it just isn’t in isolation, and more so comapred to alternatives in defi especially if you add a 90 days lock up), so if increasing capacity to 2-3x net stake would open up floodgates for more cover purchases then that feels like it should be explored. How do we understand how much more risk the mutual would be taking on by making such change? How would that play out with the 20% global limit?

1 Like
6

Can you please remind everyone how the 200k NXM was picked as the right number?

@lautumsuxen It was honestly quite hard to set this, as it requires some understanding of potential staking supply, which we were guessing at. So quite reasonable to adjust if it’s not working properly. We originally had it at 100k but that’s when we had a capacity ramp up as well. We removed the capacity ramp up because of technical challenges, so because we need Specific Risk Limit > Global Capacity Limit at the maximum we needed to increase to 200k NXM.

Specific Risk Limit = 1 x Value of Net Staked NXM
Global Capacity Limit = 20% x MCR

Whichever capacity limit is lower applies. So increasing to 2-3x Net Stake would open up capacity quicker on lower stakes.

The risk of 2-3x is allowing the mutual to take on cover when it’s not “fully backed” by stakes (1x means fully backed). This opens up an attack vector when deploying an intentionally buggy contract if it’s applied across all contracts in general. Hence my suggestion of only doing it for known protocols that have real users/purpose, but having the default setting to 1x, and then optionally increasing it protocol by protocol.

1 Like
7

Thanks @Hugh. So just so I understand: 1x net staked effectively means all the risk of a potential claim is borne by the stakers, while 2-3x means that the first 1x is borne by the stakers, while the next 1-2x is borne by NXM holders. Is my understanding correct?

8

So just so I understand: 1x net staked effectively means all the risk of a potential claim is borne by the stakers, while 2-3x means that the first 1x is borne by the stakers, while the next 1-2x is borne by NXM holders. Is my understanding correct?

Not exactly, the mutual pays all claims (rather than being split between stakers and the mutual) but at 1x an equivalent amount of NXM is burned. At 2x say, then only 50% of claims would have a corresponding NXM burn.

So this is more about incentives and making sure we prevent the attack where you stake on a bad protocol take out cover and then sacrifice the stake for the claim payment.

9

Thanks! maybe this is going a little offtopic now, but would love to understand which NXM gets burned in such a case.

Yes I can now see this risk tangibly. It’s effectively increasing the potential reward for the attacker, for the same cost.

10

Seems like the most straight forward and less technical way to address staking limitation rn is to incentivize staking. Hope the audit would complete soon, so that protocols can start depositing gov tokens to incentivize staking. This should solve all bottlenecks rn.

1 Like
11

Put some graphs together to show the impact on pricing and capacity by changing some factors:

Current situation

Low Risk Cost Limit = 200,000 NXM
Stake Multiple = 1x

image
image808×426 17.6 KB

Potential alternative

Low Risk Cost Limit = 100,000 NXM
Stake Multiple = 2x

image
image806×420 17.7 KB

Some other comments:

  • My gut feeling is we probably need to make some changes rather than just wait for bonuses.
  • There is another factor, the exponent in the price calculation, which is current 1/7. This gives the curve its shape. This could be changed to 1/10 or 1/15 to decrease price quicker but flatten out sooner, still hit minimum price at the low risk cots limit.
  • This all needs to be done in conjunction with more visibility on pricing/capacity/staking yields.
1 Like
12

I’m all in for the alternative solution as long as it brings MCR to 100k ETH asap. In the long run, I think we should also have a “flexible staking pool”.

Current pooled staking is similar to Binance savings “fixed deposit”. What if we have a flexible staking with guaranteed APR (eg 5%) similar to Binance “flexible saving”? This will encourage many people (who are lazy and reluctant to stake) to just subscribe to this “flexible staking” option. The lock-up period should be much shorter. 2 weeks? And the NXM inside this flexible staking pool can be used by the team to stake in any contract. Since you guys are the expert, you guys should be able to get >5% APR using this “flexible staking pool” NXM.

13

Thanks @Hugh and everyone else who has replied.

I understand that structural changes can take time, agreed that we probably need to look at short term solution and then long term solution over time rather than trying to rush the long term solution straight away.

The 2x/3x Net Stake changes sound interesting and a good alternative, my question is how do we deem what protocols get what rules. Minimum time since first cover? Audit performed?

I think the multiplier needs to be able to adjust by smart contract rules not by governance votes for each contract
What if we treated the multiplier conceptually like a ‘no claims bonus’ you would find in traditional insurance?

1x Net Stake: Standard baseline
2x Net Stake: Contract has had no claims in past 1 year
3x Net Stake: Contract has had no claims in the past 2 years
etc up to a maximum

However I still think this doesn’t address the impact unstaking has, in fact in almost increases it as now when someone unstakes they are now having a 2x-3x impact on the net stake for that contract based on the above.
If a gradual release of unstake is not ideal then what about a different calculation for net stake?

Net Staked NXM = Current NXM Staked - (Pending Withdrawals * 0.7)

70% is just an arbitrary number but this would at least counter the risk of prices not reacting immediately when a contract is found to be less secure but still at least provide some factor to the price calculation
I’m not sure on the best calculation but the main point is giving Pending Withdrawals a bit more weight beyond what they currently are (which is essentially treated as they don’t exist)

Another alternative could be 50% of the unstaked amount is removed from the calculation immediately but the remaining 50% rolls off over the 90 day period based on my original suggestion - giving a balance of both?

Thanks all for participating, I love that we can have these kind of conversations and even though most of us members don’t have an insurance or smart contract coding background our inputs can still have merit!

1 Like
14

@Drazav thanks again for your comments!

I really like your suggestions of “no claim bonus” and giving pending withdrawals some weight.

Bringing it together I’d like to suggest the following:

Step 1:

  • Decrease Low Risk Cost Limit from 200,000 NXM to 100,000 NXM
  • Change Net Stake = Current NXM Staked - Pending Withdrawals * 0.5
  • Capacity Multiple for existing protocols to 2x Net Stake
  • Capacity Multiple for all new protocols set to 1x

These changes should be relatively easy to implement quickly, as no smart contract changes would be required (pricing is currently off-chain), but do mean Capacity Multiples are set by governance until we get to Step 2 below.

Step 2:

Work out how to ramp up Capacity Multiple via smart contract rules rather than governance. Probably something like:

  1. Capacity Multiple starts at 1x and increases from the first time Net Stake is above some min threshold (1000 NXM) up to a max Capacity Multiple (3x) over some time period (example figures).
  2. If there is a claim restart at 1x

On timing I think we should be aiming for the following:

  • continue discussions over the next 2 days and progress to a signalling vote in Discord
  • wait for the current governance proposal to finalise which if approved would decrease governance period from 7 days to 3.
  • aim to put a proposal into governance on Friday.
4 Likes