Governance Roadmap

๐Ÿ—ณ๏ธ Mature, fully decentralised governance is a critical goal for the project - here's our plan.

Role of governance in mStable

Governors of the mStable protocol can update parameters of the system - for example changing Redemption fees, assigning rewards from the pool, or introducing new mAssets or bAssets to the system. It is important that we can fully rely on our governors to make good decisions. A critical part of the project roadmap is our decentralisation plan and an appropriate incentive/penalty system.

Implementing a mature, fully decentralised governance system is impossible to implement overnight, but a realistic plan is critical.

Capitalising on the modularity and upgradability of particular system modules, we can theorise an explicit road to decentralisation in three distinct phases.

Phases of decentralisation

For more notes on the purpose of modules picture here, check out the description in Architecture.

Phase 1

This is the initial implementation of the mStable protocol, and facilitates the core functionality surrounding mAsset usage, while also setting the framework for the transition into later phases.

Governance

3/5 Gnosis Multisig, primarily controlled by core team members and close affiliates.

Phase 1 System Modules

Phase 2

Phase 2 System Modules

Due to MTA price discovery and fair token distribution achieved through the rewards mechanism, it is feasible to begin to introduce both a more decentralised version of governance, and enable the re-collateralisation functionality.

Phase 2 sees the introduction of Re-collateralisation into the system through the Recol module, and the introduction of staking into the actual functionality of the system.

Governance

โ€‹Company Aragon DAO orchestrated by an initial council of Governors - both core team members and community stakers. Instead of merely introducing external governors in the system, there are additional intermediary steps we can take to make the transition easier (such as limiting vote proposals to a specific group).

Transition Plan

  • Deploy a Company Aragon DAO integrated by an initial council of Governors:

    • The DAO will have a Token Manager app using a custom token that will be distributed between the initial governors of the council allowing them to vote

    • There will be a Staking app as a middle layer in charge of ensuring that only Governors that have staked some Meta token are allowed to vote

    • The re-collateralisation will use the Voting app built-in in the Aragon DAO

    • The Governor will be the Agent app of the DAO allowing the DAO to call the mStable system when decided by the council

  • Transfer the Governor address to the council DAO

Phase 3

Phase 3 System Modules

Governance

At a high level, this phase sees the introduction of a Company Aragon DAO using the Meta token as the exclusive governance token. The allows us to capitalise on the wide distribution of the Meta token and the maturity of both the protocol and Aragon networks.

Transition Plan

There are a number of intermediary steps we can take throughout this deployment, but at a high level, the transition stages are as follows:

  • Deploy a new company Aragon DAO governed by the community:

    • The DAO will have a Token Manager app using the Meta token as the governance token

    • There will be a Staking app as a middle layer in charge of ensuring that only governors that have staked some Meta token are allowed to vote

    • Tweak the Voting app to decide which conditions need to take place in order to be allowed to submit Voting proposals

    • Implementation of delayed upgrades, i.e. 1-2 week implementation buffer before key system parameters are decided upon

    • The re-collateralisation will use the new Voting app built-in in the Aragon DAO

    • The Governor will be the Agent app of the DAO allowing the DAO to call the mStable system when decided by the community

  • Transfer the Governor address to the community DAO