RFC: Strategy on new product types and listings
Overview
In the last week, some members have asked about how the mutual evaluates new cover product types and how the decision to list new product types is made. I wanted to start a discussion and get feedback from members, so we can align on the mutual’s high-level strategy going forward.
At the core of this discussion are two competing goals:
-
The desire to be as permissionless as possible and to enable businesses to build with minimal restriction on top of the Nexus Mutual protocol to fuel protocol growth.
-
The need to protect the mutual against unwanted risks and to maintain alignment between existing members on the types of risks the mutual should be taking on.
It’s important to align on the broad strategic approach the mutual should be aiming for–where on the permissionless spectrum should we sit with respect to the listing process?
Heavy permissions vs. light permissions
From a strategic point of view, do we want the mutual to favour heavier permissions or lighter permissions?
Personally, I don’t think it’s possible to create a completely permissionless approach, as the shared capital pool means there is always an opportunity for the mutual to be attacked. For example: someone could propose a new product type, which opens the mutual up to a large degree of risk, or even something they are certain will claim; afterwards, that same member could buy cover and wait for a loss to occur.
With this example in mind, there must be some form of permission required to list new products and risks.
Given the mutual is under-utilising its capital right now, I think the most obvious strategic approach for the medium term (e.g., a couple of years) is to have as light a set of permissions as possible, while still retaining the ability to prevent attacks.
The counterargument here would be mutual members haven’t implicitly agreed to all the new product lines that this could result in and it’s their capital that is at risk. Taking such a view would result in heavier permissions.
A counter to the heavy permission route is that members are free to exit the mutual if they wish should they not like the direction it evolves into. While exiting can only be completed via wNXM at the moment the new tokenomics project is a key priority for the Foundation and R&D teams, which will allow members to exit the mutual if they are not in agreement with the mutual’s direction going forward.
Permissions could be set with the following dimensions in mind, either being set at one level or another or requiring different processes depending on the dimension:
- Broad business line categories (e.g., crypto vs non-crypto risk)
- Product Types (Protocol Cover, Staking Cover, etc.)
- Product Listings (Aave v3, Compound, etc.)
Members can share their thoughts on permissions and processes going forward regarding the above points.
Feedback from members
I welcome thoughts and feedback from all members on the mutual’s strategic approach going forward. Let’s talk about the benefits and drawbacks of different approaches!