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


The price of Smart Contract and Custody 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.


  • 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)


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.


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

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

  • surplus_margin = 30%


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%


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.


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 holds all funds on-chain, it will 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 investment process is entirely automated using the Uniswap protocol to initiate trades.

Each asset that the mutual holds, apart from ETH, is set to have a Min Threshold and a Max Threshold, which represents the range in number of units of the asset the mutual can hold.

If the number of units is below the Min Threshold the mutual will trade ETH for Asset, if it is above the Max Threshold the mutual will trade Asset for ETH.

Any changes to the asset list and thresholds needs to 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;

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.

Risk Assessment

Risk Assessment is the process of a member staking NXM tokens against particular risks (smart contracts for Smart Contract Cover and custodians for Custody 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 or custodian.

Deposit and Stake:

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

  2. Stakes against specific risks (contracts or custodians).

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


  • Deposited NXM Tokens are locked from redemption and transfer.

  • A Member wishing to release their stake must first request un-stake. This starts a 30-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/custodian 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 or custodian.

2. Earn Rewards

Rewards are generated for Risk Assessors when any member purchases cover on the staked smart contract or custodian. 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



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



Cover Deposit

Claims Assessor Rewards

Member Rewards




Incentive: Share of Fee Pool

Punishment: 7 day stake extension enforced.





Incentive: Share of Fee Pool

Punishment: 7 day stake extension enforced.





No incentive or punishment

Incentive: Share of Fee Pool

Punishment: None




No incentive or punishment

Incentive: Share of Fee Pool

Punishment: None




No incentive or punishment

No incentive or punishment




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.


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 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.

NXM Token

Token model

NXM can only be purchased via our app ( as it isn't listed on any exchanges. NXM can only be held and traded by members of the mutual. 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


  • 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.

Redemption and Purchase Restrictions

Several restrictions apply to the redemption and purchase of NXM tokens. Generally, these restrictions are in place to ensure the mutual always has sufficient funds to confidently pay members' claims.

  • Redemptions are restricted if MCR% is less than 100%.

  • Purchases are restricted if MCR% is greater than 400%.

  • Where are transaction would result in the MCR% being outside these limits the volume of the transaction is limited.

2. Transaction Limits Caps

Redemptions and purchases are limited per transaction to 5% of the MCR.

3. Capital Pool Liquidity

The Capital Pool must also have enough liquidity in Ether to execute on the redemption. While this is not generally expected to be an issue, this may occur temporarily if a large portion of the funds have been invested in non-ETH assets.

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.

NXM price

The token price can be fetched onchain by calling:


in the following contract:


Result returned is the NXM price in ETH terms (wei). Then multiply by 10^18 to get NXM price in ETH.

NXM volume

Use this link for The Graph with the following queries:

mintEvents(orderBy: timestamp, orderDirection: desc, first: 1000, where: { timestamp_gte: $range_timestamp }){
burnEvents(orderBy: timestamp, orderDirection: desc, first: 1000, where: { timestamp_gte: $range_timestamp }){


Contract that holds the mutuals assets:



wNXM is a 1-to-1 backed token that can only be generated by wrapping genuine NXM. NXM can only be traded among members, wNXM is fully tradable but can't be used at all within the Nexus Mutual platform. Only Nexus Mutual members can wrap/unwrap NXM here.

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..


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



Sri Lanka





North Korea

Trinidad and Tobago








South Korea



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