Nexus Mutual

[rmelbardis]

dap: 9
project name: Nexus Mutual
main site: nexusmutual.io
author: Hugh Karp (@hughkarp, [email protected]), Somish Solutions (@somish)
discussions-to: https://discord.gg/pm35wJ6
status: Draft
created: 2019-03-04

Simple Summary

Nexus Mutual is a cooperative built on Ethereum that allows people to financially cover each other against hacks/bugs in smart contract code.

Abstract

Nexus Mutual is a decentralised alternative to insurance, built as a dApp on Ethereum. We are replicating an established legal structure in the UK for p2p risk sharing known as the discretionary mutual, meaning the entire entity (a UK limited company) and its assets are owned by the members of the mutual.

The existing insurance model has significant flaws related to archaic practices and an adversarial relationship between insurer and insured. A digital cooperative model allows us to connect people together in one risk-sharing pool without the need for a coordinating profit-driven entity.

Our first product is Smart Contract Cover, allowing any member of the mutual to purchase cover which pays out if someone, not necessarily the cover holder themselves, has suffered a material loss of funds as a result of an unintended use of smart contract code. The DAO hack and Parity multi-sig issues would be examples of covered events.

Resources

• Site - https://www.nexusmutual.io/
• Code - https://github.com/somish/NexusMutual
• Dev Tools - https://nexusmutual.gitbook.io/docs/docs
• Demo - https://demo.nexusmutual.io/

Motivation

Nexus Mutual was created to improve the current insurance model by bringing it back to the cooperative structures it originated from in a socially and financially scalable way. By allowing members to share similar risks with each other, approve claims as a community and be rewarded when the mutual does well, costs and the problem of agency are reduced.
The initial product concerns hacks and bugs in smart contract code, allowing members of the Ethereum community to stake value on smart contracts they think are secure and cover themselves against risk of hacks/bugs.

We see ourselves as a protective community layer for the DeFi ecosystem:

• Other DeFi products can be covered on the platform, reducing their users' exposure to smart contract failures.
• Fund holdings rebalanced using Uniswap.
• DAI enabled as cover currency
• Funds held by the platform could in future be invested in e.g. Dharma loans, Compound, Uniswap liquidity provision, Dai Savings Rate, etc.

The long term vision involves branching out from the crypto niche and into providing accessible mainstream products (e.g. earthquake cover).

Specification

Whitepaper: https://www.nexusmutual.io/assets/docs/nmx_white_paperv2_3.pdf

Rationale

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. off-chain orders and on-chain settlement vs direct on-chain order creation and settlement. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

Building on Ethereum

Ethereum contributes:

• the ability for members of the mutual to interact with each other trustlessly;
• the ability to store the capital pool of the mutual on-chain without any single party having access to the funds
• transparency of historic transactions and the prevailing state of the dApp.

Token Model

A token was required in order to appropriately reward work input to the platform (via risk and claims assessment), control the amount of capital held by the platform and allow member participation in governance.

A bonding curve was adopted which allows for the token price to change based on:

• capitalisation level of the mutual (reflecting short-term financial security), and
• funds required by the mutual to back claims (reflecting long-term adoption)

Many iterations of the formulae have been tested - we initially struggled to step away from having 'number of tokens' as a variable in the price formula.

The token can only be bought/sold for ETH against the platform and trading is limited to member addresses only (meaning no exchanges).

More info: https://nexusmutual.io/token-model

Governance

The governance framework, built on GovBlocks, involves a system of token voting supplemented by an Advisory Board. The advisory board whitelists proposals, sets voting rewards and sets the default outcome if quorum is not reached. At any time, members can trigger a vote to replace an Advisory Board member which bypasses the whitelisting process.

As voting turnouts tend to be quite low, this is seen as a balance whereby the Advisory Board can make most day-to-day decisions, but the members have an option to override these or express their own wishes.

More info: https://medium.com/nexus-mutual/dao-governance-a-pragmatic-approach-27d529ad0819

Claims Assessment

The claims assessment methodology is driven by a legal requirement that payouts are at the discretion of (a subsection of) the membership base. Therefore, a voting system has been implemented requiring that Claims Assessors stake native tokens to participate.

We require a total stake claims voting power of 5x the Cover Amount in question. While the advisory board cannot influence the outcome of the votes, or veto any payouts, they are able to burn the Claims Assessor tokens if they are deemed to have acted maliciously.
This is a point of centralisation - solving a way to automatically slash claims assessors for malicious voting while not punishing genuine differences of opinion is a difficult research problem which has not been solved yet.

More info: https://nexusmutual.gitbook.io/docs/docs#claims-assessment

Pricing and Risk Assessment

As Smart Contract Cover is an entirely new product, the pricing model is based on
(1) the characteristics of the smart contract - initial gas, time live, transactions handled and funds held; and
(2) the amount of native tokens staked against the contract by Risk Assessors.

In order to return a price of cover, a number of complex calculations and API calls have to be performed, the gas costs of which would be prohibitive on-chain. Therefore, the quote engine is initially operated off-chain, where it signs a message when a user generates a quote. This must be combined with a user transaction to trigger the cover acceptance.

The usual data-driven insurance pricing methods based on historic experience are to be brought in later when sufficient, statistically significant data is available.

More info on pricing: https://nexusmutual.gitbook.io/docs/docs#pricing

Capital Model

In order to establish the amount of funds Nexus Mutual needs to hold, a modified version of the Solvency II framework is used (with no obligation, not being an insurance company). The Capital Model is too complex to run on-chain, so it must be run off-chain with results notarised on-chain once per day.

In the future the goal is to use trusted computation such as Trubit, zk-snarks, or Oraclize’s authenticity proofs to minimise trust levels.