Governors of the mStable protocol can update parameters of the system - for example changing platform fees, assigning rewards, changing bASSET maximum weights 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 decentralization plan and an appropriate incentive/penalty system.
Implementing a mature, fully decentralized governance system is impossible to implement overnight, but a realistic plan is critical.
Capitalizing on the modularity and upgradability of particular system modules, we can theorise an explicit road to decentralization in three distinct phases.
For more notes on the purpose of modules picture here, check out the description in Architecture.
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.
3/5 Gnosis Multisig, primarily controlled by core team members and close affiliates.
Due to Meta price discovery and fair token distribution achieved through the rewards mechanism, it is feasible to begin to introduce both a more decentralized version of governance, and enable the re-collateralization functionality.
Phase 2 sees the introduction of Re-collateralization into the system through the
Recol module, and the introduction of staking into the actual functionality of the system.
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, such as core team and investors at the beginning).
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-collateralization 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
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.
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-collateralization 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