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:
- Select the Earthquake Product Terms from a drop down menu;
- Enter the details in the Risk Specific Terms;
- Request some staking (automated via the system); and then
- 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.