Governance

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

Claims Assessment

NXM Token

Last modified 8mo ago

Copy link

Contents

Decentralisation Trade-offs