Creating More Capacity

Governance Discussions Nexus Mutual Protocol Improvement Proposals
1

Currently, seven projects are unavailable for cover. The active cover in ETH at the time of writing (May 22nd) is 283,211 and the seven projects which are maxed out contribute 85,066 of that, or 30%.

*Uniswap v3 has some very small capacity right now, but didn’t when I wrote this post

PROJECT ETH COVER REASON CAPACITY FACTOR
Curve All Pools (incl staking) 34179 MCR CAPPED 4
Aave V2 16317 Requires more staking 1
SushiSwap V1 13227 Requires more staking 1
TrueFi 8834 Requires more staking 1
Alpha Homora V1 6428 Requires more staking 1
Liquity 4752 Requires more staking 1
Uniswap V3 1326 Requires more staking 1

It’s fair to assume that any additional cover capacity that is opened up will be utilized quickly, because many of these projects are growing their own userbase and have been capped or limited on Nexus Mutual for some time.

For Curve, the only option would be to increase MCR, or for us to be more liberal with the 20% cap on any single risk (not a good idea).

However, for the other projects they all have a capacity factor of 1, I believe. I’m guessing for Uniswap v3 as I couldn’t find it listed anywhere. For comparison, Uniswap v2 has a capacity factor of 4.

Doubling the capacity from 1 to 2 for the remaining projects would still be relatively low risk. Governance proposal 118 pushed the factor from 2 to 4 for similar projects. That proposal was approved in January, so it could be done again for these other projects.

We do anticipate that all capacity factors will be reduced towards 1 for staking 3.0. But, if this is still a way away, it seems smart to increase these factors and take advantage.

Going to 2x would open up 50,886 ETH capacity. If that capacity was to be fully filled, it would represent a 17.97% increase in cover for the mutual. That’s obviously a very sizable increase in premiums, and would allow us to grow the capital pool quicker. But offering more cover also helps us to spread the good word of the mutual! Rather than having customers come to our website, only to leave frustrated day after day because capacity is not available, they get to take advantage of this new capacity. Win, win.

985,462 is being staked right now. That means only 14.25% of the potential 6,916,805 NXM is being staked.

Another way to look at it is that 10,029,355 NXM is currently staked against cover, since each NXM can be staked with 15x leverage. That’s 9.67% of the potential maximum that could be staked at any given time (with the current leverage ratios). Since this is less than the 14.25%, we know that many members are not using the full 15x leverage that is available.

So, I don’t think increasing the leverage is the way to fix this issue. Any increased leverage is more likely to be used against less popular projects, as inherently the most popular projects are those which are getting the most staked already, obviously. Plus, leverage is less likely to push those already not staking, to start. At least, compared to some other options we have.

Another option would be to incentivize staking on those projects with no capacity. This will eventually happen with pricing that scales based on demand. Again, what can we do NOW to try and improve it? Adding some additional incentive, funded by the community fund (?), to each of the above projects (excluding Curve) seems to be a good idea until Staking 3.0. Any additional staking opens up capacity and earns the mutual more premiums.

Thoughts?

6 Likes
2

Absolutely agree regarding the projects you listed above that are factor limited. They are all continually out of cover capacity, and potential customers need always come to the discord to ask about capacity that they likely will never get. An increase to 2-3x from the current 1x would seem to make reasonable sense under the current system.

Also agree mightily on the staking front - personally, I don’t stake due to the inability to spread risk without having an overly complex transaction to sign which the one time I tried it, had a transaction fee of almost 1ETH at the beginning of April (see here), thus increasing leverage would not incentivize me to stake. Additionally, the long lockup / tail burn period is somewhat of a turnoff, and I found the UI to be pretty confusing so I gave up on it. I think options like delegated staking which can reduce transaction costs (hopefully one, non-complex transaction to sign) and eliminate the need to personally research each individual project, and reducing/removing the lockup period would have a much greater effect on the proportion of holders choosing to stake. IMO ofc, based off my Nexus experience .

1 Like
3

Screen Shot 2021-05-25 at 9.04.54 PM
Screen Shot 2021-05-25 at 9.04.54 PM1184×632 93.2 KB

2 Likes
4

A bit surprised that capacity factor is 1 for AAVE V2 and SushiSwapV1. Definitely in favor to increase their capacity factor.

As for staking, I know that iTrust.finance is just around the corner and will probably incentivize delegated staking, which will lead to more coverage capacity.

5

Can you give more details on ITrust? I think we need a delegated staking front-end for NXM, not just WNXM like Armor provides.

6

@Hugh wondered if you had any perspective on this, as you were the one to recommend increasing this factor previously? I realize that your correlation risk thread calls to reduce these factors to 1 for staking 3.0, which I believe makes sense and would be necessary to reduce lockup period further. But, in the meantime I think increasing these factors could give us more opportunity to grow revenues and attract future capital.

1 Like
7

Thanks for pinging me. We have a few options here can do any/all:

1. Increase capacity factors on Aave v2 and Sushiswap

Benefits:

  • Immediate capacity increase.

Downsides:

  • We want to transition to 1x factors over time.
  • We may want to add aDAI, aUSDC for yield token cover which in my mind is a better product for both users and stakers. So may make sense to use more of our potential capacity here.

2. Increase leverage to 20x to get more fluidity in staking

Benefits:

  • Keeps capacity factor at 1x, so is more long term sustainable.
  • Probably useful anyway with yield token cover creating lots of new risks to stake on.

Downsides:

  • Doesn’t directly increase capacity in a targeted way.

3. Wait until we get more flexible pricing

Benefits:

  • Means staking rewards potentially are higher because price should increase to cater for demand.

Downsides:

  • Will take some time to implement
  • Market may not be as efficient as we anticipate, so objective may not be achieved.

Personally, I’m leaning towards 2.

2 Likes
8

Hi Hugh, thanks for your input. My problem with only increasing leverage is that we’re already seeing people failing to use the 15x leverage they have available. This tells us that there aren’t enough projects where they feel the risk / reward is acceptable.

Clearly, the ones which are maxed out are the ones where people think the risk IS worth the reward. So, increasing leverage doesn’t really help, because much of the people staking are already staking against these most popular protocols.

My opinion is that increasing leverage only helps with drawing more capacity to less popular, unloved projects. Which is awesome and I’m very for increasing levereage to 20x. But I don’t see that improving the situation for the most popular projects.

My suggestion is both 1 and 2. We can still transition to 1x factor over time, but let’s not fail to capture the demand that exists RIGHT NOW.

I would love to push for increased capacity on the other projects, not just Aave v2 and Sushiswap. These two could go to 2 and 3x capacity, respectively, in my opinion.

Uniswap v3 should probably also be 2 or 3, because it’s an established protocol that’s incredibly popular.

But the remaining three projects (TrueFi, Alpha Homora v1, Liquity) also could justify an increase in capacity factor.

3 Likes
9

Going to think more on the 2x from a long term perspective over the weekend. There might be a way to make this more long term sustainable.

2 Likes
10

https://medium.com/itrust-finance/itrust-finance-dao-the-future-of-defi-is-in-your-hands-b23cc102cee8

It seems like they will take deposits from both $NXM and $wNXM.

I’m excited about the different risk-profile staking vaults

1 Like
11

Yes, I’m excited.

I think the goal should be that at least 80-90% of NXM should be staked at all times. Hopefully iTrust helps make that happen.

12

Coming back on this. Will talk through some broader background first.

TL:DR - I suggest we can increase capacity and potential staking returns by:

  • Increasing capacity multiples to 2x across all risks, including for new listings (keeping anything > 2 at current multiples; and

  • Increase staking leverage to 20x

Background

The goal with staking is to get as much capacity into the system for a certain amount of staked NXM without opening the system up to undue risk. We need enough potential downside for stakers so they are somewhat cautious and the right risks are backed.

At a global level (across all risks) we have the general formula for capacity vs stake.

Capacity Global = NXM Staked x Avg Leverage Used x Avg Capacity Multiple

Presently the max leverage is 15x, with average being used about 10x. The Capacity Multiples vary by risk and are 1x for new protocols, 2x for Custody Cover and some others, and 4x for older protocols.

The safest way to grow capacity per NXM is a 1x capacity across all risks and increase the max leverage available, as this is less open to attack.

The primary attack vector we need to be concerned about is when we move to listing risks not controlled by the core team. If we allow more than 1x and there is permissionless risk listing then there is an easy attack vector or stake X on a weak protocol, take out cover for 2X, and extract 1X after you self exploit the protocol.

Permissionless Listing

It’s becoming quite clear to me that we can likely never have fully permissionless listing, as the risks are too great. It would be like Aave or Compound allowing anyone to list any asset on their protocol without governance votes.

So we need to develop a relatively easy way to add new listings that aren’t controlled by the core team. I think this is quite achievable by creating a long term aligned group, and it’s something we need to progress anyway to remove the Advisory Board. This is a much longer post which I won’t go into now, but for our current purposes assume that this sub-group exists and has the power to list new risks for staking.

Capacity Multiples

Under the assumption we have a robust way to control new listings, both now and in the longer term, individual capacity multiples can be higher than 1x, but we still don’t want to push them too far. The benefits are quite material, extra fluidity in the staking system as well as increased potential returns for stakers.

On balance I believe a 2x multiple can be made long term sustainable and suggest we move there for all current listings that are 1x, as well as for future new listings.

The downside here is that the core team will likely continue with the somewhat conservative approach to adding new protocols. Which I think has been working quite well so far, as we’ve avoided quite a few hacks recently because of this.

Leverage

I think it’s possible to increase max leverage to 20x as well, as this would likely help support many new risks on the Yield Token Cover side that are in the pipeline without undue risk.

8 Likes
13

Hi Hugh,

Fantastic post and I’m glad to see that you agree with me. Extremely informative, especially for those unaware of the potential attack vector that was causing us all to be cautious about capacity multiples.

I agree that moving to 2x capacity for all protocols likely makes sense. If we see that it’s introducing excess risk into the system, we will be able to have another vote to move certain / all protocols back to 1x.

In terms of staking leverage, 20x is clearly better than 15x. We moved from 10x to 15x (50% increase) in March and since then we are notably more diversified with an increased number of protocols, and the introduction of yield token cover.

I’m supportive of both of these measures and look forward to voting on it soon.

4 Likes
14

That was my guess, too. Why not increase capacity for the time it is not too risky and move back to 1x if needed. It may not be the most elegant way to handle it but a solid workaround for the benefit of our user.

1 Like
15

Have liked my way through this thread but just further echoing Dopeee’s thoughts - supportive of both measures and would like to vote as soon as practicable.

16

To be successful, we have to constantly re-assess our risk factors. I don’t know of any other DeFi cover provider that approaches things with the level of risk analysis/mitigation that we do–and that is a huge strength. I am supportive of this idea, and I don’t believe it exposes us to a detrimental amount of additional risk.

Increasing capacity factors to 2x across the board will introduce more risk, but I don’t believe it will be enough risk to outweigh the negatives in the other direction. Adding more leverage (15x to 20x) also helps us achieve more available cover as well, and I am someone who would act with 20x leverage if it were available.

I’m also going to work on educating prospective/existing members on the benefits of Risk Assessment to drive more staked NXM. We’re going to need more NXM staked if the Marketing/Comms Hub is going to execute a successful campaign over the summer.

Great job, @Dopeee for starting the discussion. Thank you, @Hugh, as always, for your experience and insight.

2 Likes
17

In general I would favour per protocol changes with increases on well established projects (aaveV2/sushi) rather than broad strokes increases especially one that includes new listings.

An increase to 2x isn’t unreasonably risky however and capacity is definitely a significant issue at the moment so the potential growth benefits definitely make it worthwhile. It is also a low effort change which makes it a good option as a stop gap until the more significant staking changes.

I don’t believe raising leverage from 15x to 20x will have a notable effect on increasing capacity for the most popular protocols but I also don’t think it will add much additional risk so I’m fairly indifferent to this aspect.

2 Likes
18

True, but it is more about providing capacity for the new listings. Staking leverage will have to grow in sync with the # of listings (as long as we require KYC). So I’m in favor of this because I want to see some more capacity for the new Yield Token Cover.

Concerning Capacity Factors, I would have preferred to increase it on protocols like Sushiswap or AAVE v2. But on the other hand, the market demands more capacity for Alpha Homora v1 / Liquity. The downside seems very limited. So I support an increase to 2x for all 1x listings.

1 Like
19

Agreed on your points, but I would ask for more caution towards Alpha Homora. There was just an exploit a few months ago and I would still recommend a bit more caution.

4 Likes
20

Want to echo others here that I like these proposed changes, but TrueFi, Alpha Homora and Liquity are all relatively new projects, I would like more confidence to be built in their smart contracts before covering them as well.

I say move to 20x leverage and move capacity to 2x for Aave, Sushiswap and Uniswap. We can revisit the changes for Alpha and new protocols going forward after a 3-6 month review period.

1 Like