Docs

In depth descriptions and technical documentation (work in progress).

Pricing

The price of Smart Contract Cover is based on three main factors:

1. Value staked by Risk Assessors against the smart contract.

2. Cover Amount selected by the user - the payout in case of a successful claim.

3. Cover Period selected by the user - the duration of the Cover.

Risk Cost

The first step is to calculate the Risk Cost based on the value staked. This reflects the expected annual outgo from the mutual of paying claims on the Cover.

Inputs

  • net_staked_nxm = Amount of NXM staked - 50% x Pending Staking Withdrawals

  • staked_risk_cost_high = 100% (maximum risk cost)

  • staked_risk_cost_low = 2% (minimum risk cost)

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

Formulae

Risk_Cost = 1 - (net_staked_NXM / low_risk_cost_limit)^(1/7)

Subject to the following criteria:

  • Risk_Cost greater than or equal to staked_risk_cost_low

  • Risk_Cost less than or equal to staked_risk_cost_high

Cover Price

To come up with the final Cover Price, an allowance is made for the Cover Amount and Cover Period (selected by the user). Finally a Surplus Margin is added to enable (1) meeting costs (such as Risk Assessor rewards and Claims Assessor rewards), and (2) creating a surplus within the mutual as a result of writing covers.

Inputs

  • cover_amount = cover amount selected by user (ETH or DAI)

  • cover_period = cover period selected by user (days) cover

  • surplus_margin = 30%

Formulae

Cover_Price = Risk_Cost x ( 1 + surplus_margin) x cover_period / 365.25 x cover_amount

Capacity Limits

The mutual places capacity limits on the amount of cover that is available on specific risks. These exist to protect the mutual as a whole from being too exposed to any single risk it takes on. The are two limits, a Specific Risk Limit based on the amount of staking on a particular risk and a Global Capacity Limit based on the overall capital resources of the mutual. The lower of the two limits applies in each case.

Specific Risk Limit

Capacity on any particular risk is limited by the amount of staking on that risk. If there is no staking, the mutual cannot offer any cover.

Specific Risk Limit is equal to :

capacity factor x net_staked_NXM

net_staked_NXM as per the pricing section above

Capacity factor is either 2x if a cover purchase was made prior to governance proposal #88 or 1x otherwise. The capacity factor will be defined more concretely in the future via governance.

Global Capacity Limit

This limit is based on the financial resources of the mutual and is there to ensure the mutual is not overly exposed to any particular risk, regardless of how much is staked:

Global Capacity Limit = MCReth x 20%

where:

MCReth is the Minimum Capital Requirement in ETH terms.

More detail about the Minimum Capital Requirement and our assessment of the correlations between smart contracts is available in the Capital Model section below.

Minimum Capital Requirement (MCR) and Capital Model

The MCR is used directly in the token price formula and is therefore an important component of the entire Nexus Mutual system. The MCR represents the minimum amount of funds the mutual needs to be very confident it can pay all claims. It is represented by the following formula:

MCR = Max (MCR Floor, f(Cover Amount))

MCR Floor

The long term goal of the mutual is to have the f(Cover Amount) drive the MCR calculations but the mutual needs an MCR Floor value in the early phases so that there is a critical mass of capital to enable cover growth.

MCR Floor History

  • May 2019 - At launch, the MCR Floor was set at 12,000 ETH, this level needed to be reached before cover purchases were enabled for the first time.

  • June 2019 - Members decided to lower the MCR Floor to 7,000 ETH to enable cover purchases to go live sooner.

  • November 2019 - Members decided to implement a dynamic MCR Floor to help meet concentrated demand on a smaller number of systems. If the mutual had excess capital (defined as having a MCR% greater than 130%) then the MCR Floor value would increase by 1% per day.

  • July 2020 - Members decided to increase the frequency of the MCR Floor increment to 1% every 4 hours (if the MCR% was above 130%) until the MCR Floor reached 100,000 ETH.

  • September 2020 - 100,000 ETH MCR Floor was reached and the MCR increment speed reverted back to 1% every day (if the MCR% was above 130%).

  • October 2020 - Members decided to switch off the MCR Floor increment, and MCR Floor currently stands at 162,424.73 ETH

f(Cover Amount)

Long term the MCR should be driven by the amount of cover the mutual has written as well as other risk factors like how well matched assets are with liabilities.

Nexus Mutual currently implements the capital model by assuming a fixed gearing factor applies to the active cover in ETH terms. This is a simplification of the full Capital Model which is described in detail below. If the full Capital Model (which is run off-chain) starts producing results that are materially different to the current gearing factor it is anticipated that the factor will be updated via a governance action.

f(Cover Amount) = Active Cover in ETH / Gearing Factor

Gearing Factor currently = 4.8

Capital Model

The capital model determines the minimum amount of funds the mutual needs to hold. Nexus Mutual uses actuarial mathematics derived from the Solvency II methodology as developed by the European Insurance and Occupational Pensions Authority ("EIOPA") to set its Minimum Capital Requirement ("MCR").

There are two main components making up the MCR calculation:

  1. The Best Estimate Liability (or “BEL”), representing the expected loss on each individual cover.

  2. A Buffer, representing the funds the pool requires to survive a 'black swan' event.

Similarly to a traditional insurance entity, Nexus Mutual will hold (and invest) a Capital Pool of assets in excess of the MCR in order to back its covers (see Assets and Investment). The ratio between the Capital Pool and the MCR is known as the coverage ratio and abbreviated to MCR%.

Note that the MCR is subject to a lower limit below which it cannot fall. This level is currently set at 7000 ETH.

Best Estimate Liability

The BEL will initially be equal to the total Risk Cost across all active covers on the mutual's books.

In the future, as we begin to gather experience on the outcomes of covers, we will be able to create a more accurate BEL which also allows for the remaining duration on each individual cover. Currently, the BEL for each cover represents the entire Risk Cost regardless of remaining duration - a prudent assumption resulting in higher reserves required per cover.

Buffer

The Buffer represents the funds that Nexus Mutual will hold, in addition to the BEL, in order to protect itself against unforeseen adverse events. The intention (with no obligation) is to follow the Solvency II framework and calibrate this amount of funds to a level where the mutual can survive a 1-in-200-year adverse event. In practice, due to the uniqueness of the Smart Contract Cover product, some deviations from the SII texts are initially necessary.

Smart Contract Cover Module

The Smart Contract Cover Module is based on the exposures Nexus Mutual has to the covers it has written. The inputs to the model are:

  1. Total Cover Amounts CA(i) for each individual smart contract

  2. Correlations Corr(i,j) between each pair of contracts.

  3. Scaling Factor SC which is calibrated to make the capital result as a whole more comparable to a full Solvency II calculation.

The correlations between each pair of two contracts are established by parsing the respective verified smart contract code, removing comments and spacing, and establishing the proportion of identical text.

These inputs are fed into the following formula to produce a Capital Requirement CR across all covered contracts within Smart Contract Cover:

CRSCC=SC×i,jCorr(i,j)×CA(i)×CA(j)CR_{SCC} = SC \times \sqrt{\sum_{i,j} Corr(i, j) \times CA(i) \times CA(j)}

Currency Module

The currency module allows for possible fluctuations in the value of other currencies (initially only DAI) relative to the value of the base currency (ETH).

50% stresses in both directions are applied to the value of the other currencies in order to establish the impact on both the assets and the buffer requirement of the mutual.

Final MCR as per Capital Model

The Currency Module scenario with the lowest resulting MCR% coverage (across both the BEL and the Buffer) is picked out. This MCR% coverage is then applied to the Capital Pool in order to inform the choice of Gearing Factor.

Assets and Investment

Investment Returns

Investment returns are an often under-appreciated aspect to insurance as it allows the insurance entity to earn returns on the reserves it holds. It is a key component to insurers’ profitability and therefore is a critical aspect for Nexus Mutual is able to compete with existing insurance entities longer term.

As Nexus Mutual will hold all funds on-chain, it will initially restrict itself to assets of ETH and ERC20 tokens only. At present this asset universe is quite small but it is expected to grow substantially over time. The initial investment process is entirely automated using the Uniswap protocol to initiate trades. A buy and hold investment strategy will be defined and trades will re-balance the pool as required. There are also trading triggers to deal with liquidity needs arising from claim payments.

Any changes to the asset list or weightings will be approved by the Members through the governance module. Ideal assets would generate a positive return over time with very high probability, akin to the portfolio composition of traditional insurers which tend to be dominated by corporate and government debt instruments.

Overall Investment Strategy: Consistent with existing insurers, the investment strategy will be conservative with the aim of earning incremental returns without endangering the solvency of the fund. Additionally, it will be largely buy-and-hold focused to minimise trading activity and therefore fees.

In the Ethereum world, we see the current most appropriate candidates for generating a return as:

  • locking up ETH to generate interest in the proposed Proof of Stake system,

  • investing in financial instruments based on decentralised collateralised lending;

  • investing in interest-yielding decentralised money markets;

  • acting as a guarantor in state channel and payment channel networks;

Unfortunately, we are still some time away from Ethereum moving to a Proof of Stake system. With the increasing scale and liquidity available in the various decentralised lending markets, this is a more likely rout to obtaining a return in the short term. The mutual does not currently have the capacity to invest in assets other than ERC20, but this is not considered a major issue in the short term given the observed short policy durations of the initial product. Nexus Mutual has launched without any investment assets (see Trading), only holding currency assets (ETH and DAI).

Asset Liability Management

Entities with a known set of liabilities (such as discretionary mutuals and insurance companies) must hold assets to back those liabilities. The potential pitfalls associated with poorly matched assets in terms of liquidity requirements or exposure to economic changes poses several financial risks for these entities. Asset Liability Management (or "ALM" for short) refers to the practices employed to minimise those risks.

Most ALM strategies involve making sure that:

  • the change in the value of the assets on some basis is consistent with the change in the liabilities on the same basis, within certain tolerance limits; and

  • sufficient liquidity is available as and when it is needed.

For Nexus Mutual, at least initially, ALM considerations are not a significant concern, owing to:

  • The expected short-duration nature of Smart Contract Cover, and

  • The initial currency assets being held (Ether and Dai) intended to match denominations of the covers written.

The initial Capital Pool asset raise following launch was be denominated in ETH. Upon successful completion of the Capital Pool funding, a portion of DAI (currently expected to be 5% of the initial pool) will need be purchased in order to enable the writing of covers denominated in DAI. As the cover portfolio matures, and the currency profile of the covers becomes clearer and more stable, the mutual will aim to match its currency holdings to its cover exposures as per the trading strategy.

In future, if Nexus Mutual begins writing longer-duration covers and/or employs a different investment strategy, the mutual should look to employ more sophisticated ALM methodologies.

A more detailed overview of common insurance ALM practices can be found here.

Trading

Trading processes are built on the Uniswap exchange.

There are two broad classes of assets, or sub-pools, of the Capital Pool:

1. Currency Assets

These will be the list of all currencies cover can be purchased in (currently ETH and DAI). The primary purpose of holding currency assets will be to pay claims and redemptions when they are due, so the main goal is to provide liquidity. Therefore, currency asset holdings should be sufficient to always pay claims but minimised so that the amount of funds attributed to investing assets is maximised, thereby maximising potential return for the pool.

The Currency Asset (CAx) list will initially contain the two purchase currencies, ETH and DAI.

It will also contain a “Base Minimum” (BMx) amount which represents the lowest target number of each currency that should be held for liquidity purposes. Note that the “Base Minimum” isn’t a hard floor that must be met at all times, it is a target.

There is also be a Variable Minimum (VMx), which starts at zero for each currency asset. VMx is then increased when a claim is submitted in currency X by the claim amount and is decreased by the claim amount when a claim in that currency is either paid or declined. In other words, VMx equals the total claims cover amount in currency X that is pending a claims decision.

Asset

Base Minimum (BMx)

Variable Minimum (VMx)

Ether

TBA

Floats based on pending claims.

DAI

TBA

Floats based on pending claims.

2. Investing Assets

The fundamental goal is that investing be done in a fully automated and trust-less way.

In the absence of immediately implementable alternatives (as outlined in Investment Returns), there will initially be a defined list of ERC20 assets (and ETH) that the fund will invest into.

The performance of any single ERC20 token being superior to ETH is by no means guaranteed and at launch the intention is to keep the Investing Assets and Currency Assets the same - ETH and DAI. However, if the Nexus Mutual membership base believe strongly that the Capital Pool should contain any additional ERC20 tokens, this can be achieved via the Member Governance process.

Asset

ER20 Token Name

Target Min Holding %

MinIA%x

Target Max Holding %

MaxIA%x

Ether

ETH

​TBA

​TBA

Dai

DAI

​TBA

​TBA

TBA

Relative Holding Scores

In order to decide which assets to trade the investing assets need to be ranked (once per day) in order to identify two assets:

  1. the asset furthest below its MinIA%x (the lower bound of the percentage of the overall pool), and

  2. the asset furthest above its MaxIA%x (the upper bound of the percentage of the overall pool).

This will be done by means of calculating a Relative Holding Score - Low (RHSL) and a Relative Holding Score - High (RHSH) for each investing asset.

RHSL = [# of IAx . fx(IAx) / V ] – MinIA%x

RHSH = [# of IAx . fx(IAx) / V ] – MaxIA%x

Where:

  • # of IAx is the number of asset x being held

  • fx(IAx) is the latest daily inverse exchange rate to Ether (e.g. if Ether is worth 300 DAI, then fx(DAI)= 1/300)

  • V is the size of the total size of the Capital Pool in Ether.

Where trades are triggered for liquidity purposes they need to determine which other asset is bought or sold. The RHS values are used for this purpose. The RHSH indicates the first asset to be sold, and the RHSL indicates the first asset to be bought.

Trading Triggers

A fully defined set of rules is required to trigger all trades with the objectives being:

  1. Move funds in excess of liquidity needs from the Currency Asset Sub-Pool into the Investing Asset Sub-Pool.

  2. Move funds from the Investing Asset Sub-Pool into the Currency Asset Sub-Pool when liquidity needs increase.

  3. Rebalance holdings within the Investing Asset Sub-Pool when the portfolio mix deviates too far from the desired mix.

Of these #2 is more time sensitive, as there need to be funds to pay claims, with #1 and #3 being less time sensitive.

Excess Liquidity Trade

For each Currency Asset initiate trade when;

# Holdings in CAx > 2 x (BMx + VMx)

This check is triggered at least once every four hours.

Each such trade is of size

# Holdings in CAx - 1.5 x (BMx + VMx)

Insufficient Liquidity Trade

For each Currency Asset initiate trade when;

# Holdings in CAx < (BMx + VMx)

This check is triggered at least once every four hours.

Each such trade is of size

1.5 x (BMx + VMx) - # Holdings in CAx

Re-balancing Trade

Re-balancing trades aim to shift assets within the investment sub-pool when a particular asset becomes over- or under-weight. This is challenging to execute if there is insufficient liquidity between the two assets needing to be traded and complicates the logic of the smart contracts. Due to these issues, while different events can trigger a trade, re-balancing trades will always sell the highest ranked RHSH asset for Ether. This will then increase Ether holdings and subsequently trigger an Excess Liquidity Trade to purchase the most underweight asset (lowest RHSL value). The following triggers describe the first trade only, as the second trade is already described above.

For each Investing Asset, initiate trade when either:

Number of IAx x fx(IAx) / V > MaxIA%x + z% ; or

Number of IAx x fx(IAx) / V < MinIA%x - z%

Where z% is a parameter, currently set at 1%.

If V = 0 or there are no assets in the Investing Asset pool then no trades are initiated.

Triggers are checked once per day when the fx(IAx) rates become available and there can only be one re-balancing trade per-day, even if multiple trades meet the trigger criteria.

Risk Assessment

Risk Assessment is the process of a member staking NXM tokens against particular risks (smart contracts for Smart Contract Cover) they think are secure. It allows any member to purchase cover at reduced prices and rewards the staking member with additional NXM tokens.

1. Deposit and Stake NXM Tokens

A member wishing to stake NXM tokens against a particular risk may use any tools that they wish to determine how likely a claim is to occur. The staking process simply provides a market based signal by offering lower prices when more value is staked on the contract.

Deposit and Stake:

  1. Choose how much NXM to deposit for staking purposes.

  2. Stakes against specific risks (contracts).

  3. You can stake your deposit up to 10 times provided each stake is less than or equal to your deposit.

Unstaking:

  • Deposited NXM Tokens are locked from redemption and transfer.

  • A Member wishing to release their stake must first request un-stake. This starts a 90-day unstake lock-time, at the end of which the stake will be released.

  • Stakes that are in the unstake lock-period continue to earn rewards and are exposed to potential punishments if there is a claim.

  • To withdraw your deposit you must unstake and wait for the lock-period to expire. Withdrawal can only be made if your maximum stake on any contract is less than your deposit AND your deposit is staked less than 10 times.

The price of cover on the chosen risk is reduced based on the number of NXM tokens staked at the time cover is purchased. For details on the calculations see the Pricing section.

Stake NXM tokens against a smart contract.

2. Earn Rewards

Rewards are generated for Risk Assessors when any member purchases cover on the staked smart contract. Staking by itself does not generate rewards, a cover purchase is also required.

When cover is purchased by a member, 50% of the Cover Price in newly minted NXM tokens is awarded to Risk Assessors on a proportional basis.

Earn rewards when others purchase cover.

3. Burnt Stakes

If there is a successfully paid claim, Risk Assessors on that risk have their stake burned on a proportional basis up to the claim amount (converted into NXM at the prevailing NXM price). If the stake is not enough to cover the claim amount in full then all stakes are burned, in this case the mutual as a whole bears the remaining claim cost without any offset.

Stakes can be burned if a claim occurs.

Claims Assessment

Claim Submission

The first step in the claims process is for a member to submit a claim, to do this the member must stake a deposit in the form of NXM tokens which comes from the 10% of NXM tokens that were locked when purchasing cover. The required deposit is 5% of NXM tokens, which means a member can submit a claim for assessment twice. If the claim is accepted the deposit is returned, otherwise it is burned.

Claims Assessor Voting

Claims Assessors must stake value, in the form of member tokens, before they are allowed to assess claims. Any NXM token holder can become a Claims Assessor. Assessing claims in line with the consensus outcome earns Claims Assessors additional member tokens, while voting against the consensus outcome results in the assessors tokens being staked for a longer period.

To ensure fraudulent voting is prevented, a Claims Assessor's stake can be burned by the Advisory Board. Burning tokens is a judgement call made by the Advisory Board, it is not automated based on voting results. For more details see the Governance section.

To become a Claims Assessor for the first time, any amount of NXM can be staked for the initial staking period. When voting on a claim the stake period is extended by the staking extension period (7 days). Should the assessor vote with the consensus outcome, this extension period is removed, should they vote against the consensus outcome it remains in force.

When submitted, a claim first goes to the Claims Assessor group for voting. When voting on a claim a Claims Assessor's entire stake is applied to that claim as the voting weight. This is used to determine the voting outcome as well as determine the proportionate share of Fee Pool rewards.

The voting period lasts for a minimum of 36 hours, after this point the vote automatically ends on the earliest of either when

  • voting stakes of greater than 10x the cover amount have voted; or

  • 72 hours have passed.

The stake weighted voting outcome then determines the claim result. A claim is escalated to a full member vote if either:

  • Voting consensus is below 70%; or

  • Voting weight is less than 5x the Cover Amount.

Member Voting

If the claim proceeds to a full member vote then all members, regardless of whether they have staked NXM for Claims Assessment or not, can participate in the vote. To do so they lock all their NXM for 2 days and in return earn a share of the Fee Pool. Tokens locked in this way cannot be redeemed or transferred to other members but can still be used for other actions within the mutual (similarly to the Governance lock-in period).

As per the Claims Assessment vote, the voting period lasts for a minimum of 36 hours and ends when either the total voting stake reaches 10x the Cover Amount have or 72 hours have passed, whichever occurs first. A simple majority outcome is used to determine the claims outcome. Should the minimum 5x voting weight not be achieved in the member vote, the claims outcome is then determined by the earlier Claims Assessor vote using a simple majority basis.

In addition, a Claims Assessor cannot vote on more than one claim every 6 hours, this is known as the Velocity Period.

Claims Assessment Parameters

Parameter

Value

Initial Stake Period

30 days

Minimum Voting Threshold

5x Cover Amount

Maximum Voting Threshold

10x Cover Amount

Minimum Vote Period

36 Hours

Maximum Vote Period

72 Hours

Claims Assessor Velocity Period

6 Hours

Fee Pool

20% of the Cover Price

Cover Holder Deposit

5% of Cover Price in NXM Tokens

Stake Extension Period (Claims Assessors)

7 days

Member Vote Lock Period

2 days

Flow Chart for Claims Assessment

Full voting flow for Claims Assessment

Claims Assessment Incentives and Punishments

Outcome

Claim

Cover Deposit

Claims Assessor Rewards

Member Rewards

A1

Pay

Release

Incentive: Share of Fee Pool

Punishment: 7 day stake extension enforced.

N/A

D1

Deny

Burn

Incentive: Share of Fee Pool

Punishment: 7 day stake extension enforced.

N/A

A2

Pay

Release

No incentive or punishment

Incentive: Share of Fee Pool

Punishment: None

D2

Deny

Burn

No incentive or punishment

Incentive: Share of Fee Pool

Punishment: None

A3

Pay

Release

No incentive or punishment

No incentive or punishment

D3

Deny

Burn

No incentive or punishment

No incentive or punishment

Claims Resolution

Once a claim decision has been finalised, if the claim has been approved then the Cover Amount is paid to the Cover Holder's address, cover is ceased and the deposit is released.

Should there be insufficient funds in the liquidity pool then claim payment is attempted again in 24 hours. This process continues for 60 days, after which it is assumed there will never be sufficient funds and the claim is not attempted again.

Should the claim be declined, cover remains active and the Cover Deposit used to submit the claim is burned.

Claims Assessor (or Member) rewards are also distributed at this point. As with other rewards, NXM are not automatically allocated to the Member Address (primarily due to gas considerations). NXM rewards shall be minted and sit in a pool from which the member can subsequently withdraw their rewards. This allows members to wait and claim several rewards at once in order to reduce gas costs.

Governance

For an overview of Nexus Mutual's proposed governance framework, please see our blog post on DAO governance.

Nexus Mutual's governance framework is built on four main principles:

Principle #1: Use of the Members' funds held in the capital pool shall be decided by the membership base as a whole.

Principle #2: Lack of member participation on a day-to-day basis should not prevent the mutual evolving.

Principle #3: Safety of funds stored is critical and outweighs centralisation concerns until code safety has been proven.

Principle #4: Decisions and control should remain with the Membership base as a whole wherever possible.

Advisory Board

The Advisory Board is currently made up of five members of the mutual and contains members of the founding team and other experts. The goal is to have a qualified mix of individuals covering the three broad skill sets of:

  • Technical Expertise: Smart Contract Security and blockchain,

  • Technical Expertise: Insurance and Mutuals

  • General Expertise: Legal, Regulatory, Corporate Governance and Business Management.

As described above the Advisory Board has power in limited circumstances and is primarily there to provide qualified technical guidance to the members of the mutual as well as enact emergency functions should they be required.

Proposals

Proposals are the method by which Members can decide on governance activities and the mutual can adapt and change as required.

  1. Raise: The first step is for a Member to raise a proposal via the Governance mechanism.

  2. White-List: In most circumstances the proposal is then sent to the Advisory Board who white-lists the proposal by categorising it and setting the total NXM token rewards to be shared among those participating in the vote.

  3. AB Vote: The Advisory Board then votes on the proposal to provide a technical and informed view of the proposal to all members. For regular proposals the Advisory Board vote result also sets the default outcome should the quorum not be met.

  4. Member Vote: The proposal then proceeds to a full member vote, which is binding.

  5. Implementation: In some circumstances, such as simple parameter updates or extraction of funds, the proposal is then automatically implemented by the code. For others there would be an additional step where new code is developed and a further proposal is undertaken to upgrade to the new version or not.

As described in the above overview there are some actions the Advisory Board can take by themselves, Emergency Actions, and there are others where the decision is deemed to be critical (or a Special Resolution) in which case the default result will always be decline.

Importantly, replacing an Advisory Board member bypasses the white-list process and can be enacted by any member at any time, ensuring that the membership base as a whole is in control.

Key Parameters

  • Quorum (Regular Resolutions): 15% of voting power

  • Quorum (Special Resolutions): 75% of voting power

  • Majority (Regular Resolutions): 50%

  • Super-majority (Special Resolutions): 75%

  • Voting Weight: 1 + NXM Tokens (capped at 5% of total vote per Member)

Decentralisation Trade-offs

The following are the major points to be aware of:

  • Emergency Control - in this early phase, Nexus Mutual is currently unilaterally upgradeable by the Advisory Board. This control is entirely for safety reasons and is intended to be permanently forfeited within 3-6 months after launch.

  • Emergency Pause - Advisory Board members have access to an emergency pause function, which stops all transactions. All Advisory Board members have agreed to only using this in extreme circumstances. The emergency pause allows a code upgrade to be completed before any further transactions complete. All code upgrades (outside the Emergency Control period) must be agreed to by the membership base.

  • Proposal White-List Process - The Advisory Board initially white-lists all governance proposals (with some exceptions, e.g., replacing Advisory Board members) as well as assigns them a default voting outcome (Yes or No). If the quorum isn't reached the default outcome proceeds.

  • Off-Chain Capital Model - The Capital Model is run off-chain due to high gas costs. Results are notarised on-chain once per day. We plan to move this on-chain in the future once heavy computation solutions (e.g. Trubit or zkSnark-based) become viable. The capital model code will be made open source so anyone can verify the results if they wish.

  • Off-Chain Pricing Model - The pricing model is run-off chain due to gas requirements. Arguably, there is less need to run this in a fully decentralised fashion but it will still be made open source so anyone can verify the results if they wish.

  • Claims Assessment Punishment - the Advisory Board has the power to burn staked NXM that participates in the Claims Assessment process if they deemed that fraudulent voting occurred. A decentralised way of punishing fraudulent voting is extremely hard to achieve as it needs to distinguish between genuine difference of opinion and fraud. We aim to conduct adequate research and remove this aspect in time.

Several of the elements described above are significantly offset by the Overthrow control, which aims to put a decentralised check on the Advisory Board's power:

'Overthrow' Control - Any Advisory Board member can be replaced by another member if the membership base agrees. These proposals by-pass the white-list approach and therefore cannot be interfered with by the existing Advisory Board. We consider this control to be a substantial counterbalance to the day-to-day centralised elements that exist.

Token Model

Nexus Mutual uses a continuous token model, also referred to as a bonding curve. This means tokens can be purchased at any time but at a variable price. This contrasts to more common ICO-type approaches where there is a fixed purchase period with set price change points, followed by a speculation-driven market on exchanges.

The token price varies based on two primary parameters:

  1. The funding level of the mutual; and

  2. The amount of capital required to support the covers written.

The main driver of the relative short-term price is the funding level of the mutual, reflecting the immediate financial position and encouraging re-capitalisation when funding levels are low. In the long term, the required capital to support the covers will rise to reflect the adoption of the platform.

Token Price Formula

TP = A + (MCR / C) × MCR%^4

Where:

  • TP = Token Price in Ether

  • A and C are constant values which were calibrated at launch:

    • a = 0.01028

    • c = 5,800,000

  • MCR = the value of the Minimum Capital Requirement in Ether which grows as the number of covers grows.

  • MCR% = ratio of the Capital Pool to the Minimum Capital Requirement.

The MCR is determined by the Capital Model and is calibrated to achieve a 99.5% probability of solvency over a 1 year period.

For a general purpose understanding of the token model please visit the Token Model page.

Purchase Restrictions

Due to gas restrictions, the smart contracts do not use the full integral of the bonding curve to determine the token price. Instead, they allow purchases of up to 1000 NXM to be purchased at one price. For any purchases over 1000 NXM, tranches of up to 1000 NXM prices are calculated in succession to determine the overall price.

Redemption Restrictions

Several restrictions apply to the redemption of NXM tokens for Ether which are to ensure the mutual always has sufficient funds to confidently pay members' claims.

1. Capital Pool > MCR

The funds in the Capital Pool need to be above the MCR. Specifically, the MCR% needs to be greater than 100%. The redemption transaction will fail if this is not the case.

2. Redemption Caps

Redemptions are also capped per transaction to prevent a large redemption dropping the MCR% ratio below 100%. Specifically, the maximum NXM that can be redeemed at any point in time is as follows:

Max Redemption = (MCR% - 100%) x 2000

3. Capital Pool Liquidity

The Capital Pool must also have enough liquidity in Ether to execute on the redemption, as well as pay any pending claims. Therefore any redemption transaction will fail if the redemption will decrease the Ether held in the currency asset pool to be less than 50% of the Base Minimum Amount. Please see the Trading section for further detail.

4. Redemption Price

To discourage speculative buy/sell behaviour the redemption price will be set at 2.5% lower than the purchase price derived from the Token Model.

Legal Framework

Nexus Mutual is a company limited by guarantee and is registered in England & Wales. Full details are available at Companies House where you will also find all the official legal documentation such as the Articles of Association and Member Rules.

Articles of Association

The official Articles of Association are also available separately at Companies House. The Articles describe the purpose of the mutual, who can join the mutual as well as other important legal information. Some of the most important points are summarised here:

  • Limited Liability - each Members liability is limited to £1. This means if the mutual was to ever run out of funds each member would be liable to provide an additional £1 only.

  • Register of Members - as each member becomes a guarantor of the mutual it is required that they be listed on the register of members. This register is held by the mutual (off-chain) and contains the Names and Contact Address (or substitute) for each member.

  • Wind-Up - if the mutual is to be wound up, for example, on agreement by the members, then any funds in excess of contributions made (for example from investment earnings) are to be donated to charity. This ensures the mutual as a whole can never make any profit.

  • Withdrawal - the mutual may request that any member withdraw from the mutual. This would only be enacted via a membership proposal in a relatively extreme situation where the member's participation endangers the ongoing operation of the mutual.

Member Rules

The official Rules of the mutual describe the operations of the company which are implemented via the Mutual's Smart Contracts..

Membership

The application process for becoming a Member of Nexus Mutual Limited is as follows:

  • pay the Membership fee of 0.002 ETH;

  • successfully pass a Know Your Customer check.

Unfortunately Membership is restricted due to various laws and regulations so we can't accept Members from the following countries:

Restricted countries

China

Japan

Sri Lanka

Ethiopia

Mexico

Syria

Germany

North Korea

Trinidad and Tobago

India

Russia

Tunisia

Iran

Serbia

Vanuatu

Iraq

South Korea

Yemen

Tax

As a discretionary mutual, Nexus Mutual conforms to mutual trading law in the UK. For reference see HMRC's Business Income Manual. As a result products are not subject to Insurance Premium Tax (IPT) in the UK with any distributions or surplus being taxed in the hands of members. In addition, the mutual will pay tax on any trade outside of the mutual. The main implications are:

  • The mutual needs to pay VAT on the membership fee.

  • The mutual needs to pay corporation tax on any investment income.

  • Members are responsible for their own tax affairs, in particular when they receive more from the mutual than what they have contributed.

This information is for background purposes only, it is not tax advice, and should not be relied on. Please seek your own independent advice.

Deployed contract information

See https://nxm.surge.sh/