RFC: Approve the Addition of Delegated Claims for Select Product Types

Governance Discussions
1

RFC: Approve the Addition of Delegated Claims for Select Product Types

Overview

The Foundation and DAO teams have been prioritizing growth in cover sales and onboarding new syndicates (i.e., staking pool managers with an existing distribution pipeline). We’re currently working to onboard a new syndicate that can meaningfully contribute to the growth of cover sales. This syndicate will require additional functionality to offer new Product Types through their staking pool, specifically the ability to delegate to an Ethereum address as a designated assessor.

This functionality would enable certain Product Types to have a designated third-party claim assessor as defined in the cover wording for that Product Type. If someone were to buy cover for a Product Type with delegated claims enabled, then claims for that Product Type could only be assessed by the designated claim assessor.

On behalf of the Foundation and the DAO team, I propose that members approve the addition of Delegated Claims functionality for select Product Types. Doing so will enable the Mutual to onboard new types of syndicates with established distribution in onchain and offchain markets.

Rationale

One soon-to-be-onboarded syndicate and several potential syndicates have indicated they need to define who is responsible for claim assessment as a core business requirement, making the delegated claims functionality a material requirement for onboarding them as syndicates.

Specification

For certain Product Types, there will be a requirement to have a designated Claim Assessor rather than opening the claim vote to all members, as we currently do for our Product Types.

A Delegated Claims system would allow specialized assessors to review a claim. This functionality would allow the Mutual to underwrite new Product Types and access new lines of business. This feature would give syndicates and their respective clients an option to specify a more familiar claims process that is closer to traditional insurance, rather than the standard process where any NXM holder can vote.

Technical Specification for Designated Pool Managers

This Product Type will be designed for bespoke deals underwritten by syndicates (i.e., staking pool manager(s)). When listing a Delegated Claims Product Type, the Advisory Board will need to specify the Designated Pool Address(es) AND the Designated Assessor Address in the onchain data. Only the Designated Staking Pool(s) will be able to stake against listings within a given Delegated Claims Product Type.

Once a Delegated Claims Product Type is listed and a Designated Pool Manager has staked against a listing under that Product Type, the Foundation Frontend team will denote that the listing for this Product Type uses Delegated Claims in the UI.

The Designated Assessor Address for a Product Type can be updated in the future, but only the Advisory Board will have the power to update a Product Type’s onchain data.

Technical Specification for Designated Claim Assessors

When a cover holder submits a claim, the Designated Pool Manager will be responsible for notifying the Designated Claim Assessor. The Designated Assessor Address will be the only address that is registered and able to vote on the claim.

If an address other than the Designated Assessor Address tries to vote, that member will see a message telling them that voting on this claim is not available because this cover is for a Product Type that uses the Delegated Claims method.

Proposal Status

This RFC will be open for review from 19 September until 3 October. If there are no substantial comments and feedback during the review period, this RFC will transition to an NMPIP.

The NMPIP will be open for review for seven (7) days before moving to an onchain vote on Thursday, 17 October.

3 Likes
2

Wanted to outline my support for this proposal.

After many conversations with various companies operating in the insurance world (either core crypto/DeFi, crypto adjacent or non-crypto) it has become very clear that we simply need this functionality to access certain opportunities.

There are several new and novel items about Nexus that do cause pause to operate with us (crypto backed, onchain only, discretionary cover) but the claims functionality does appear to be a key barrier that can be relatively easily adjusted at the protocol level.

Potential clients question the ability of some unknown people on the internet having the required skills to assess complex non-crypto claims, which is a fair challenge. The proposed adjustment would allow the Advisory Board (when it lists new products) to set the claims process to either be Normal or Delegated. If Delegated a particular member would be the solve vote in the claims assessment process.

This allows the Mutual to employ other experts, like TPA’s, to conduct claims assessment which is relatively common practice within the wider insurance industry. I’m confident this would open up, quite widely, the range of potential deals and product lines Nexus Mutual can support.

The potential downside is the resilience of the overall protocol to claims attack, which I don’t consider to be a material risk because:

  1. The Advisory Board retains the decision on enabling delegated claims (or not) for a particular product.
  2. The claims cool down period of 24hrs remains, so any claims attack can still be mitigated in the normal way.

Overall, I believe this is a relatively simple protocol change, that opens up a lot of potential growth and doesn’t have any material downside risk.

3 Likes
3

This functionality unlocks the next generation of the protocol.

Highly supportive of this change and excited to see what happens next.

3 Likes
4

Hello all,

I’m extremely excited to present our first contribution to the growth of Nexus Mutual.

I hope our experience at Native (Pool 28), a commercial insurance syndicate, offers a unique perspective on the proposed Delegated Claims Authority RFC. Our expertise spans both traditional insurance practices and DeFi, positioning us to bridge these sectors effectively.

We support the implementation of Delegated Claims Authority, recognising its potential to enhance Nexus Mutual’s service offering. This change aligns with the evolving needs of the insurance market, particularly for clients from traditional finance exploring decentralised solutions. The following sections outline the benefits, opportunities, and considerations of this proposal, informed by our experience in integrating established insurance processes with onchain cover.

Benefits of Delegated Claims Authority

Increased Consistency and Expert Assessment

By allowing for delegated claims authority, we can ensure a consistent and professional claims service across complex product types. This consistency is paramount in building trust with clients, especially those from traditional finance backgrounds who heavily rely on standardised insurance processes for certainty. With delegated authority, we can implement standardised assessment criteria and procedures, ensuring that each claim is evaluated with the same level of scrutiny and expertise, regardless of its complexity or the specific circumstances surrounding it.

This change enables claims to be assessed by highly qualified experts. In our case, we work with a number of third-party administrators (TPA) who are collectively the world leaders in digital asset insurance contracts, claims and law. Our TPAs bring years of experience in handling digital asset-related claims, understanding the intricacies of blockchain technology and the unique risks at the intersection between onchain & traditional businesses.

This level of specialised knowledge is crucial when dealing with complex, crypto-native insurance products. Their expertise extends beyond just technical knowledge – they also understand the regulatory landscape and best practices in risk management for digital assets. This depth in experience and capability ensures that claims are not only assessed accurately but also in compliance with relevant insurance regulations and industry standards.

Alignment with Traditional Insurance Processes

The proposed system brings Nexus Mutual closer to traditional insurance processes, which is vital for increasing confidence among large, established businesses considering crypto-native insurance solutions. Many potential clients from traditional sectors are hesitant to engage with alternative (typically unregulated) ‘insurance’ platforms due to a lack of credit rating and unfamiliarity with the claims process. By implementing a delegated claims authority system within Nexus’ capabilities, we’re taking a closer step to bridging DeFi and traditional insurance, a core goal of Native.

This alignment will significantly lower the hurdles for traditional businesses to purchase onchain cover, allowing them to rely on a claims process that feels familiar and trustworthy. It also opens up opportunities for Nexus Mutual to potentially collaborate with traditional insurance companies, creating hybrid products that leverage the strengths of both decentralised and traditional systems.

The Attributes of Claims Assessors

A key strength of this proposal is the ability to assign a trusted claims assessor at the time of binding coverage. This flexibility offers several advantages:

  • Reduces ambiguity in the claims process: By clearly defining the assessor at the outset, all parties involved in the coverage agreement have a clear understanding of how potential claims will be handled. This transparency eliminates any confusion or disputes that might arise from an opaque or evolving assessment process. We can promote the designated assessor’s credentials and track record as part of the Nexus Mutual proposition, further boosting credibility in the coverage.

  • Allows for tailored expertise based on the specific product type: Different insurance products often require different types of expertise for accurate claims assessment. For instance, an EVM smart contract vulnerability claim would benefit from an assessor with deep knowledge of Solidity and blockchain architecture, while a claim related to Bitcoin mining data-centres might require expertise in property, energy and ASIC mining operations.

    The ability to assign specific assessors to different product types ensures that each claim is evaluated by the most qualified expert for that particular area, leading to more accurate, informed and fair assessments.

  • Enhances trust and transparency for the cover buyer: Knowing who will be responsible for assessing potential claims provides an additional layer of assurance for the cover buyer. It allows them to factor in the reputation and expertise of the assessor when making their decision to purchase coverage. This transparency can be a significant selling point, especially for institutional clients who need to demonstrate due diligence within their own risk management processes. Note that claims assessors, much like underwriters and brokers, are only as good as their reputation for fairness and nuance; adding a renowned TPA to the process increases accountability and transparency to the entire process.

Overall Benefit to the Ecosystem

By seamlessly combining Nexus’ transparency with traditional insurance practices, the implementation of delegated claims authority represents a significant upgrade for the Mutual and the onchain risk ecosystem.

This hybrid approach maintains Nexus Mutual’s decentralised ethos while introducing necessary specialisation for complex, high-stakes claims. It naturally creates a potential tiered system where community assessment handles simpler claims, and specialised assessors manage more complex ones, ensuring efficient resource use and maintaining community involvement. Ultimately, this change positions Nexus Mutual to compete more effectively in the broader insurance market, opening doors to new partnerships, product types, and customer segments previously out of reach.

Preserving the Mutual’s Interests

We support the safeguards outlined by Hugh, including Advisory Board control over product types using delegated claims and the retention of the 24-hour cool-down period, maintaining the protocol’s resilience while enabling necessary flexibility.

Additionally, we would like to also include commentary on the confidential nature of commercial insurance claims. Our proposed change suggests that claims evidence available to traditional insurers and TPAs cannot be fully disclosed due to sensitive commercial information. This necessitates a level of trust in delegated claims assessors to act professionally, even without full transparency to the entire Mutual. To balance this, we propose that a defined group of Board members, with appropriate clearance, could review sensitive claims information on behalf of the Mutual. This approach preserves confidentiality, allows us to hybridise onchain cover with traditional insurance claims processes and maintains Mutual oversight.

We welcome further discussion on ensuring the security and accountability of delegated claims assessors, including processes for resolving potential disputes between assessors and the Advisory Board.

3 Likes
5

I agree this is a positive to unlock new growth.

What are the current NXM staking requirements for Pool Managers?
Wouldn’t it make sense to increase it for Pool Managers that have Delegated Claims enabled?

6

Hey @Gauthier,

There are no requirements for someone to create their own staking pool, other than being a member of the Mutual. However, the Advisory Board must add new product types and listings, so no staking pool manager can permissionlessly create their own product types without working with the Advisory Board first.

The staking pool managers who work with the Advisory Board to create a product type with delegate claims enabled and have established distribution will be the ones to determine which staking pools they want to underwrite this risk. In most cases, the staking pool manager who creates the product type with delegated claims enabled will be the sole underwriter.

Let me know if that answers your question or if I can answer any other questions :turtle: