Nexus Mutual: A Decentralized Insurance Mutual

Background

In the early concepts of insurance, people used to group together to form a community. This community collects resources to protect individual members against calamity. Hence, all funds raised can be used to accommodate the affected members. Now, imagine you are in a decentralized world, where the staggering growth in DeFi is assisting you all day long, and suddenly, a Hacker or a simple bug in your smart contract slashed all your money. What will be your reaction? In the past, we have seen such hacks and bugs that resulted in the loss of a multi-billion dollar, such as the infamous DAO attack in 2016, where a hacker drained 3.6 million ETH by exploiting a recursive call bug. To compensate for the threat of losing money Hugh Karp in 2019 came up with the idea of Nexus Mutual.

This article will help us understand the core functionalities and implementation of Nexus Mutual.

Introduction

Nexus Mutual is a decentralized insurance platform that creates insurance products. It is a community-backed alternative to insurance that uses a risk-sharing pool. The first launched product of Nexus is a smart contract cover. This cover provides coverage against smart contract vulnerabilities.
The traditional insurance structure carries substantial unnecessary costs in the system. These costs come in the form of insurance premiums, frictional costs and other profit margins. Nexus Mutual aims to disrupt the traditional insurance model by using blockchain technology, allowing peer-to-peer insurance mutual to be created in a cost-effective and scalable way.

In the following few sections of this article, we will cover all the major components and mathematical models of Nexus Mutual. We start with Nexus Membership.

Membership

Identity

Nexus uses KYC identification to provide membership. By having a membership, each member becomes a guarantor of the UK based company. The members are also required to pay a joining fee. Note that this identifying information is not held on-chain and processed only once while signing up.

Token

An ERC-20 compatible token NXM is created to serve as an internal incentive mechanism. The members of the mutual can hold NXM, which represents their membership rights. NXM is restricted to Nexus mutual members, and only KYC’ed users can hold it.

A continuous token model is used to identify the price of NXM while purchasing. The token price varies based on two factors.

1. The funding level of the capital pool.
2. The minimum amount of capital required to support existing covers.

Continuous Token Model

NXM uses a continuous token model to determine the price of the NXM token based on how the mutual is performing financially.

Mathematical representation of the continuous token model.

Where,

• TP = Token Price in Ether
• MCRETH= The minimum amount of capital required to support existing covers. The MCR is calibrated to a 99.5% solvency level.
• MCR% = Ratio of capital pool funds to the Minimum Capital Requirement.
• A and C = Fixed constants, based on the prevailing Ether price before launch.

The above function takes the total asset value and the minimum capital required in Ether. This function uses the total price formula to calculate the price of NXM.

At first, when the funds get launched, no cover can be purchase until the pool has sufficient staked value in Eth. This to ensure that the cover is safe to use.

Minimum Capital Requirement

The MCR is the level of funds required to pay all the claims. A fixed minimum value of MCR has been set before its launch. It is a significant component of the mutual, influencing price and redemption conditions.

The getMCR function took the public values of MCR and desired MCR. The virtual MCR value moves towards the desired MCR, and away from the stored MCR value at a constant velocity based on how much time has been passed from the last update time.

MCR%

MCR% is a ratio of ‘funds held’ to ‘funds required.’ The mutual has adequate funds when the amount of money it holds is greater than the MCR.

The price of token decreases if the size of the capital pool decreases. For example, When the claim is paid, the capital pool shrinks, but the MCR remains unchanged, resulting in the decrease of MCR%, which reduces the token price.

The exact process will be repeated if the capital pool increases due to the purchase of any cover, increasing the token prices.

The given calulateMCRRatio function calculates the MCR ratio. The additional multiplication of 10^ MCR_RATIO_DECIMALS is to avoid the float division.

Token Allocation

NXM can only be bought and sold on the Nexus Mutual platform, and it can only be created in the following ways.

Purchase via The Token Model Price

Anyone can purchase tokens via the Token Model Price. When funding is required, the price of the token will be low, as discussed earlier.

Claims Assessment Rewards

An additional amount of tokens are allocated as an incentive to claim assessment. This amount is limited to a fixed percentage of the cost of cover.

Risk Assessment Rewards

A specific amount of tokens are allocated to reward the members for participating in the risk assessment.

Governance Rewards

Additional member tokens are allocated as an incentive for participating in governance. The supply of the member token is not fixed. However, all methods of generating new tokens require a specific contribution to the Mutual as discussed above. These membership tokens can be used or burned in the following ways:

• If the cover has been purchased, 90% of the tokens are burned, while the remaining 10% are locked for the cover period to submit a claim.
• To participate in the claim assessment and earn the resulting income, member tokens must be staked.
• Similarly, in risk assessment, to earn a commission, a stake is required.

Redemption

If the pool has sufficient funds, the redemption of member tokens in exchange for Ether is permitted. But this comes with the following restrictions.

• Capital pool needs to be above MCR(MCR% >100%).
• Redemptions are capped per transaction.
• The capital pool must have enough liquidity in Ether.
• The selling price will be 2.5% below the prevalent purchase price.

One important thing to mention here is that these tokens can not be transferred to any Ethereum address that has not been designated as a member.

The _getStakerRedeemedStakeCommission function is to get the staked commission redeemed by the staker for a particular contract at the given index. This function takes the staker address and staked index as an input and returns the amount earned at the specific index.

The makeCoverBegin function enables the users to purchase the cover with funding in ETH. This function takes the cover currency, cover period, cover address, and the user’s digital signature as input. If the provided details of the user qualify the requirements, the user will get the cover.

Claim Assessment

There are mainly two approaches to claims assessment using blockchain technology. First, using an oracle which is an off-chain information provider, and second, using crowd-sourcing information with voting mechanics. The mutual prefers to depend on a crowd-sourcing approach due to sudden oracle failure and limited product set.
It is difficult to incentivize the members in the insurance context because there is a clear incentive to defraud the pool. Members can buy the cover depending upon how much stake the application has, which determines the coverage available, and the cover price.
Let’s understand how members can defraud the pool. For example, in crowd-sourcing, a member can buy the cover with low coverage, then use a substantial amount of cover to pay off the claims assessors and pocket the difference.

To solve this issue, Nexus Mutual has bound the claim assessors to stake a significant amount of tokens. The stake is deposited for a specified period and then returned if the claim assessors act honestly.

Incentives Structure For Claim Assessors Voting

1. Voting with a consensus outcome entitles Claim Assessors to earn a share of the fee pool. This fee will be in the form of additional member tokens and valued at a fixed percentage of the cover cost.
2. Voting against the consensus outcome will result in the locking of stake for a longer period.
3. Voting power will be added up to 5X the cover amount. This voting power is determined by the number of tokens that have been staked.
4. If no consensus is reached between the claim assessors, the overall fee of the pool reduces.
5. Member tokens become inactive for 12 hours after participating in a claim assessment.

This method prevents submitting many fraudulent claims of total value well above the staked amount and then approving them all. In such Conditions, the advisory board has the authority to burn all the member tokens if too many false claims are approved.

If a member has submitted a claim, the claim assessors will verify the claim’s authenticity by submitting a vote. The claim assessors submit a verdict as an input that is 1 to accept and -1 to deny the associated claim Id. The claim assessors add the vote against the id and, in the end, change the claim status.

Capital Model

The Capital Model determines the minimum capital the fund needs to hold. The alternative approach of the Capital Model could be to 100% collateralize the insurance contracts, essentially holding the total sum assured values at all times. This method will provide a high level of assurance to the consumer. However, this comes at the cost of reduced capital efficiency and the ability to raise funds.
Let’s understand the above technical explanation with a simple example. Assume, Nexus has 10,000 contracts, each with a chance of 1% claim for a sum assured of $100.

Where we are donating: n=10,000, p=1%, v=$100

In this example, we expect only 1% of the Total Exposure to be paid in claims, but with 10,000 contracts, the mutual only need 1.26% of the Total Exposure to be confident that the fund will be solvent. Thus, by collateralizing 100% insurance contracts, the capital efficiency will be reduced. To mitigate this issue, the Capital model presented the Combining Module.

Combining Module

The Capital Model is structured in multiple modules, where each module(M) represents a product and a currency pair. To account for currency risk, the Currency Module(fx) has been introduced. These modules are then combined at a total level to get the MCR(as we have calculated above). In conclusion, there will be three modules, M1, fx, and CM, for one product and one currency.
The base calculation currency is Ether as the pool is Ether-dominated. However, the MCR of each module is calculated in its currency (i.e., DAI) and then converted into Ether in the combining module.

To begin with module1. Assume the product has a fixed sum assured MCRM1 as defined below:

Where,

• Corr(i,j) is the Correlation matrix of the individual pricing risk cells.
• Exp(i) is the Total Probability-weighted exposure (or cover amount) in pricing risk cell(i).

The Correlation matrix will be simple if the independence between the cells is assumed.

Now, for the second step, the currency module(fx), which takes the MCR’s of each module in a particular currency(k), compares that with the value held in poll V. This module also applies a currency shock of 50% both up and down and then chooses the maximum value.

The combining module takes a similar approach to the MCRM1 calculation, where correlation is between different modules.

The total MCR will need to be calculated often, for once per day, so that funding may trigger if required. The calculations for the Capital Model will be handled off-chain due to gas requirements while the result being notarized on-chain.

Funding

The funding is all effectively governed by the Continuous Token Model, responsible for the increase and decrease of token price. Another aspect of funding is the multi-currency pool of funds. It is vital to ensure the right level of funds in each currency as the members’ fees and claims are constantly flowing in and out of the pool.

Governance

Not all potential actions can be defined in the code. There are always fallbacks options that are required in several circumstances. For this purpose, Nexus Mutual has set up an advisory board responsible for taking decisions in extreme scenarios. The Governance has no custodial rights to the pool funds; neither can release funds to any particular person. The core authorities of Governance are mentioned below.

1. Facilitate the members in scenarios where the codebase doesn’t allow automatic implementation.
2. Punish the claim assessors if acted dishonestly.
3. Implement emergency pause in the functionality if required.
4. Perform white-listing on proposals where required.

All future updates and recommendations must contain the voting outcomes (e.g Yes/No) as well as the recommendations of governance.

Pricing And Capacity Limits

To develop a complete Pricing framework, Nexus Mutual has introduced the concept of decentralized risk assessment, which involves experts as smart contract security auditors staking value in the form of member tokens against specific risk to deduce the cost of the cover amount. If an early claim event occurs, then part or all of the stake of the auditors will be lost. In return, the risk assessors will earn a commission in member tokens for the cover sold.

Cover products prices are mainly based on three factors:

1. Value staked by risk assessors against the protocol.
2. The cover amount selected by the user is a payout in case of a successful claim.
3. Cover period of the contract.

Risk Cost

Risk Cost is the annual expected outflow from the mutual for paying claims on the cover.

Formula

Where,

net_staked_NXM= Amount of NXM staked — 50% x Pending Staking Withdrawals.

low_risk_cost_limit= = 50,000 NXM (amount of stake required to reach the low risk cost).

Cover Price

The Cover Price is the final price for a specific Cover Period. A fixed surplus margin of 30% is added to accommodate risk assessors and claim assessors.

Formula

Where cover_amount is selected by the user(ETH or DAI).

The other risk mitigation technique is Capacity Limits. This is a relatively simple approach that will be taken in cases where exposure of a single smart contract occupies a fixed percentage of the pool. This ensures that any single claim will not risk the solvency of mutual funds.

Investment Returns

Investment Returns are a key component of the Nexus Mutual profitability and the ability to compete with the existing insurance entities. Nexus Mutual holds its funds on-chain while restricting itself to assets of ETH and ERC-20 tokens only. The investment process is entirely handled by Uniswap protocol. A buy-and-hold investment strategy has been defined, and trades will re-balance the pool. There are three ways to generate the investment returns on ETH, and these are.

1. Locking up ETH to generate interest in them in the proposed proof of stake system.
2. Investing in a financial instrument(or contract) based on collateralized lending.
3. Acting as a guarantor in state channel or payment channel networks.

Conclusion

Nexus is a people-powered alternative to insurance, currently providing coverage to all the main Defi protocols. In the future, it is expected to improve the crypto-economic design, pricing mechanics, and investment earnings as well. Nexus promises to provide technical progression while providing the most challenging products and protection for its members.

To know more about the on-chain financial metrics of Nexus, you can click here.

Glossary

Capital Model: To define how much capital is required to back the risks.

Investment Returns: Insurers hold customer money and invest it to earn additional returns until the claim event occurs.

Governance: A way to upgrade the code in line with the wishes of the membership base.

Capacity Limits: An approach to operate within a specific range.

Pricing: A method for determining the fair risk charge for the risk cover.

References

1. Karp H., Melbardis R. (n.d.). Reterived from https://nexusmutual.io/assets/docs/nmx_white_paperv2_3.pdf
2. Karp H., Melbardis R. (n.d.). Reterived from https://nexusmutual.gitbook.io/docs/
3. Petrie K., (2020). Reterived from https://medium.com/nexus-mutual
4. Nexus Mutual (2020) Github:https://github.com/NexusMutual

Also read about Synthetix.