DAO Governance: A pragmatic approach

Governance is a tricky topic when it comes to blockchains. Lots of theory, lots of philosophy, lots of passionate discussion but unfortunately little directly applicable evidence to base decisions on. While we have the whole of human history to learn from, choosing how best to apply this knowledge to a specific blockchain project is challenging.

At Nexus Mutual our approach is to acknowledge upfront that we don’t have all the answers. Our goal is to deploy something that seems objectively reasonable, see how it works in the real world, and then change it in response to new evidence.

Deploy. Learn. Iterate.

Diving in; Nexus Mutual is a DAO. It holds members funds in a common pool and uses those funds for a specific purpose. In our case, as a pool of capital to pay claims arising from the provision of Smart Contract Cover to its members. Nexus Mutual members can also decide to change any aspect of how the mutual operates by upgrading parameters in the code, or even the entire code base itself.

Designing Our Initial Governance Model

When designing our governance model we identified three key concerns. Firstly, member participation, we want high participation but recognise that holding member attention as well as the gas costs involved in voting mean this is a challenge. Secondly, we want to ensure we minimise any centralisation, especially because our DAO is a real company and we have a legal requirement to have a board. Thirdly, we strongly anticipate the need to upgrade our code and therefore wanted to avoid stagnation if member participation was low.

While we are still working out some of the details, this has lead us to the following key elements for our initial governance model:

• There is a board of, say, 5 members that “white-list” proposals (with some exceptions).
• The board provides a recommended outcome for each proposal.
• Votes are put to the entire member base for a token weighted vote (capped at 5% maximum weight).
• Majority outcome prevails if the quorum of 15% is reached.
• If the quorum isn’t reached the board recommendation proceeds.
• Tokens are locked for a period of time after participating in voting, to ensure those voting have a vested interest in the outcome of the votes (see EIP1132: Extending ERC20 with token locking capability)

In addition we have several elements to encourage wider participation:

• There are token rewards for participating in the vote. We recognise voting requires members attention and strongly believe attention must be paid for.
• Rewards are split between the number of members voting, rather than number of tokens voting. Making it worthwhile for all members to participate.
• A member can delegate a proxy to vote on their behalf and still receive all their rewards in the vote. A proxy can be any other member and may be revoked at any time.

To reduce the elements of centralised power sitting with the board:

• Any member can raise a proposal to replace a board member with themselves which bypasses the “white-list” gate.
• If accepted by the membership then they automatically join the board.
• The board has no input on this process apart from voting in their own capacity as a member.

This model results in low levels of pragmatic centralisation on a day-to-day basis which is balanced by the ability to over-throw that power at any time. We believe this is a good trade-off between relying on experts to both move faster and respond to any emergencies vs what the community might view as full decentralisation.

How the voting structure might look with proxy (delegate) voting.

Modular Governance

Returning to our deploy, learn, iterate approach; this will all be made possible because our solution is built on the GovBlocks platform. GovBlocks affords us a modular approach to governance that can be easily changed if necessary. We can tweak voting weights, rewards, quorum levels, virtually all components of the governance process.

But perhaps the most useful feature is the ability to implement “automatic actions”. Where technically possible, automatic actions allows any changes agreed in the proposals to be deployed automatically. For example, changing a board member, changing a specific parameter in the code, or even designating a new smart contract for the entire code base. This means proposal results can be implemented automatically after the vote has closed removing the need for a separate deployment step.

GovBlocks actually enables us to deliver on our goal of building a living breathing organism that can be fully controlled by its members. That is what decentralisation is about, giving power and control back to the individual.

Conclusion

Building governance structures for blockchain applications is still in the very early stages. We believe learning from experience is key to improving our understanding and informing design choices. The sooner we can deploy the sooner we will have hard evidence to act on.