Towards New Risks

Governance Discussions Nexus Mutual Protocol Improvement Proposals
1

The wider vision for Nexus Mutual is to provide hardened infrastructure for underwriting and capital coordination for any type of risk. And when I say any type of risk I really do mean anything; earthquake, hurricane, crop insurance, Taylor Swifts’ voice etc. This is like a super efficient version of Lloyds of London. But how do we get there?

On the surface this may seem very challenging but the current protocol along with planned changes can actually achieve this in a relatively short time frame. It’s hard to estimate these things, but to give some context, quite likely less than 12 months.

So what would this look like and what needs to happen to get there?

The general idea is that anyone should be able to bring any new risk to the mutual, and simply add it, like adding a new token pair on Uniswap. No governance process should be required. Nexus Mutual Risk Assessors then choose whether to stake or not, if they do, cover is offered at the price and limits determined by the staking amounts. Once some staking has occurred other members then simply purchase cover.

Conceptually this is like an insurance broker bringing all the relevant documents on a specific risk to Lloyd’s of London where an underwriter reviews the details and offers a price, or not.

So a new product is simply a written description that details what events need to occur for a claim to be valid, the cover wording. Risk Assessors determine if they want to back the risk by staking and Claims Assessors would then interpret the cover wording document when deciding on claims.

More specifically, to make this work we likely require three levels of cover wording or terms, all of which apply:

1. Global Terms - this applies to all risks the mutual offers, and would likely include some “boilerplate” like terms. Global Terms should be set by governance and should only be changed very rarely.
2. Product Terms - this is a specific cover wording document for each product, eg Smart Contract Cover, that anyone can design and bring to the protocol.
3. Risk Specific Terms - for specific risks within a product line clarifications or adjustments may be required. For example, with the Curve pools that get released reasonably regularly users need to understand which pools are covered by the ID and which aren’t. For many new products, the unique identifier needs to reference a specific risk, eg earthquake cover at a specific longitude/latitude.

Once we have all three levels of Terms these are linked to a specific unique identifier (ID) which can be referenced for members wishing to either stake for Risk Assessment, purchase cover or for Claims Assessment. In the case of Smart Contract Cover the contract address acts as both the ID and the Risk Specific Terms (by identifying the specific risk being taken on), but these concepts can be separated for new products.

Detailing this further with a few examples: Earthquake cover would have separate Product Terms. So if you want to get cover for a specific location you:

  1. Select the Earthquake Product Terms from a drop down menu;
  2. Enter the details in the Risk Specific Terms;
  3. Request some staking (automated via the system); and then
  4. Purchase cover.

Alternatively, if you want to start writing a new product with different terms and conditions, for example slashing risk for ETH2.0 staking, you bring along a new product terms document that applies to ETH 2.0 stakers in general plus you specify the precise details for the specific staker (eg their ETH address). From then on any other ETH2.0 staker can use the existing product cover wording and add their specific details to get cover.

Such an approach has a huge amount of flexibility as the underlying Nexus code is designed to be minimal. All the complexity of terms and specific risk pricing models sits almost entirely outside the protocol and is effectively brought on-chain in the most minimalist way.

So how do we actually get there:

1. Pooled Staking - as mentioned previously this is a fundamental building block for most future development. Release coming soon ™
2. Simplified Pricing - we need the pricing model to work with only one input, the amount of NXM staked. Release coming soon ™
3. Partial Claims - we need the ability to pay partial amounts of cover for partial loss as this will open up the design space for new products enormously. Research currently ongoing.
4. Cover Wording Architecture - link the 3 layers of cover wording to an ID and make sure the details are stored on-chain so that it is clear what terms apply to each cover. Not yet started.

As you can see, these building blocks are actually well underway and while Nexus Mutual only offers Smart Contract Cover for now this won’t be the case for long.

1 Like
2

Thanks Hugh, it’s great to discuss what Nexus could become above and beyond crypto. I do believe that, by democratizing risk assessment, Nexus, with it’s more capital efficient model, should be able to better price risk on the long tail than any other legacy insurance institution. And it’s fantastic that this is technically within reach.

The main question is whether it’s feasible to go after new risks in the short term. In crypto Nexus has an edge in that there is a captive audience that at the very least has heard of it, but what distribution efforts would be required to expand beyond it? And does Nexus have the resources in the short term to do that?

3

I think these extensions towards new types of risk will expand the scope of Nexus Mutual within crypto already, no need to extend beyond it (for now).

4

The main question is whether it’s feasible to go after new risks in the short term. In crypto Nexus has an edge in that there is a captive audience that at the very least has heard of it, but what distribution efforts would be required to expand beyond it? And does Nexus have the resources in the short term to do that?

Our approach here is to focus on expanding coverage with crypto risks first. We think there is a massive market that insurance companies aren’t able to access due to lack of knowledge, so we have a significant advantage here. This will likely be the case for a few years. On the tech side we want to build the protocol to be flexible and extensible to any type of risk, this will maximise the protocols potential, so we’re building for the future.

So while we’ll primarily focus on expanding distribution within crypto for now if someone approaches us with a new risk they want cover for, outside crypto, then we can do it really quickly on a more opportunistic basis.

2 Likes
5

Sounds really cool and would forward for the implementation.

1 Like