Reduce 90d staking lock-up period to 30d

Governance Discussions Nexus Mutual Protocol Improvement Proposals
1

As Hugh has flagged, a reduction in the 90 day lock-up period is planned for ‘Staking 3.0’. However, the full implementation will still take some time. I propose reducing the 90d lock-up period to 30d ahead of the full implementation for the following reasons:

-The 90d lock-up period has driven a low level of staking participation on the platform, and we are in a less than optimal situation where users prefer to find equivalent or better yield on wNXM via LPing on AMMs without the issue of illiquidity. Low staking participation fundamentally slows the growth of the NXM platform to provide more breadth of cover, but in my view, is also putting off new capital entering the mutual to find yield and capital appreciation. Speculators would prefer to hold wNXM and find yield outside of the platform. Speaking openly, as a long term participant and holder of NXM I personally do not see the illiquidity trade-off as sufficient at current staking yields, but would be interested in staking if this was reduced to 30d.

-The development of a yNXM vault with yearn is in progress and this requires the vault to be able to withdraw staked capital on NXM with more flexibility than 90d. This vault has the potential to bring multiple short-term benefits to NXM including a) supply of ETH capital to help improve the buffer on the MCR% above 100%, b) increase the breadth of contracts staked to allow NXM to enter a lateral phase of growth and c) enable greater coverage purchase by other vaults for their own strategy. The vault design has been created and is in progress, but the developers require a 30d lock-up period in order to deploy test vaults for the strategy and this cannot be progressed further at this stake. In order to streamline this process and accelerate the benefits of integrating further with yearn, a change to the lock-up period is required sooner than the full launch of ‘Staking 3.0’.

@Hugh I would be interested in your views on any constraints and risks we may need to consider on reducing this lock-up period, and whether this would be possible to implement ahead of the full launch of ‘Staking 3.0’ in order to attract new capital, encourage more staking on the platform and allow the development of the yNXM vault.

8 Likes
2

Thanks @gyoung10, great that you have raised this.

On the risk side, the proposal does open up the mutual to more risk, primarily in the following situations:

  1. When brand new unaudited projects are added
  2. When average cover purchase periods are longer

We can control #1 as a team by being a bit more conservative in adding new protocols, especially anon ones without audits. We’re doing this quite a bit anyway tbh.

Also, the average cover purchase periods are quite a lot shorter than we anticipated so 2 is less of a risk then originally envisioned.

More broadly, the mutual needs to start scaling faster and that can only happen by encouraging more staking. Therefore on balance I believe this is worthwhile as a bridge until Staking 3.0.

Note on implementation: technically when someone starts the unstake period the current unstake period parameter (90 days) is selected at that point. This means any unstakes already in the pending 90 period would still remain at 90 days even after the change. However, stakers would be able to request a new unstake after the parameter change and therefore start the 30 days countdown, which could resolve sooner then the current unstake request.

5 Likes
3

I like this idea lot. Increasing general staking levels is important reducing the lock up time should only help encourage that. Like Hugh mentioned, the average cover purchases periods are fairly short (which makes sense since a month of cover is exactly 1/12th the cost of a year of cover), which should hopefully make this easier to implement.

1 Like
4

I would stake more for sure if the lock-up is reduced to 30d.
I agree :+1:

5

I thought this would require smart contract work that would distract devs form staking 3.0. In any case, I’m all for it and would love to vote on it.

6

Update here:

We’re just working out the best way to implement how existing unstakes will be treated, as it does require a small technical change. Aiming to put this into governance next week once we’ve sorted out the best solution.

3 Likes