Governance
Governance is a tricky thing that requires more careful consideration than just minting a governance token and calling it done. Incentives are critical. Economics are critical.
Malt's long term plan is to be fully governed in a decentralized manner. The question is how do we get there in a way that makes sense for the innovation of the tech as well as the desire to decentralized for all the benefits that come with that.
Here are some core principals we are thinking about:
- 1.The protocol itself should be governance minimized - some things about the core stability protocol will have to change over time but the surface of possible changes should be as small as possible.
- 2.However, to get to point 1 we must be sure that all other variables are correctly set. This requires them to be update-able in the short term until we find the point to lock them in.
- 3.The broader Malt ecosystem around the protocol should be community governed.
- 4.Governance rights should go to those who provide value not just those with the deepest pockets
- 5.Long term decision making should be incentivized over governance decisions that benefit in the short term.
It's our opinion that most projects fail at governance in one way or another. It is a very hard problem that has not been solved at scale yet. However, there are many interesting ideas floating around and we plan to contribute some to that body of knowledge.
Initially, the team maintain control of the changes to the core protocol itself. We are the ones who built it and we will be the ones to continue to build it and maintain it over time. Once we are happy that certain parameters are in the right place then we will burn the ability to make changes to those again.
There is one caveat to the team control that is worth mentioning. All contract changes that could be considered a "rug vector" are locked down behind a timelock contract. This includes things like minting new Malt or withdrawing funds from protocol capital sources.
In the cases where those things need to be done there is a forced wait period before the action can be executed. So should anyone on the team go rogue or we get compromised in some way then the community gets several days to notice and take action.
This is a good middle ground between giving the team the control they need to innovate in the short term without giving them any power that could be abused to the detriment of the community.
While the team maintains control of updating protocol parameters there will still be scope for community to make suggestions for the protocol as well as for other off-chain issues that need to be worked out. For these we will make use of Snapshot.org to provide off-chain voting.
This can be things like (but not limited to):
- 1.Deploying a new pool
- 2.Deploying on a new chain
- 3.Team compensation plans
- 4.Treasury usage
The voting rights themselves will likely be linked to bonded LP.
Last modified 1yr ago