So far a few core developers were able to update the Mango v3 Program at will. The main reason for this decision was that governance currently takes at least 3 days to approve any change. I’d like to make everyone aware that this poses a significant security threat to the DAO as unauthorized access to the program can cause loss of all funds currently deposited.
There have been frequent changes to the program, even a month after it’s initial release. Security issues and bugs have been fixed behind the scenes, not an a daily basis, but a few times. It’s clear to everyone involved, that the ability to upgrade the program within minutes, is an important feature and not a bug and we should retain it.
Given the incompatibility of the governance program, i’d like to highlight a possible alternative. For the last months Project Serum has been using a multi-sig to control their program updates and I’d like Mango to take the same step.
Let’s create a new body of governance: the developer multi-sig, curious to hear everyone’s ideas, who should be on it.
There is actually no need to resort to another governance solution for program upgrades because the current governance program could be used for that. There are two potential solutions here:
Create a new realm and mint 1 governance token to each community member who should have voting power for upgrades.
This way it works the same way as Multisig with the added benefit of using the same UI as the DAO and ability to add more members.
Note, if it’s not mathematically possible to change vote outcome the proposal is tipped automatically and there won’t be any delay in executing upgrades if the members vote.
Another option is to add the community members to the current DAO as a council.
The governance program supports an optional council which can be used exactly for the purpose of fast-forward votes. The added benefit would be using a single UI and DAO and both the community tokens holders and the council could vote on program upgrades. Time critical upgrades could be voted on by the council and other upgrades could be voted on by the community.
The only issue with this approach would be too much power given to the council, because in the current design the council can vote on the same governances as the community. A simple solution to this is to add a flag to all governances which would allow or disallow council vote, and the flag itself would be controlled through governance vote.
Note, the community can also vote to remove the council if it abuses its power, so they would be accountable.
I think having governance for program updates is a good idea and I’d like to see that that’s ideally where Mango heads. I also like Sebastian’s idea of distributing a single governance token to whoever is part of the council, but I do have a question about the flexibility of the voting parameters in a governance solution scenario vs multi-sig.
Namely, what sort of voting windows can be arranged and how do we obfuscate the updates?
This is especially important in the case of a security update, because if the voting window is long enough and the update is to fix a security/distribution issue, is the information public enough someone can do something nefarious with it?
And then for obfuscation, I’m thinking of is the bug we had in the token-sale contract (Bug Bounty for Exploit in token-sale contract). Being able to quietly fix this was obviously important, so how do we stop this information being public before the update, even if it’s only for a short time)?
Do we have the controls to only allow update token holders to view the vote and severity ranking votes to set the voting windows?
What do you think about a governance specific council model? I can see how we would like to create more councils pretty quickly, in order to speed up decision making on a lot of issues, like developer grants for instance. Not sure if it’s better to have more realms or just a lot of specific councils.
My preference would be to have multiple councils within the same realm. This way the councils would act like an elected board of directors which represents the community interest and makes day to day decisions to run the DAO. The community would still be able to make decisions on the same matters as the council and also change the council.
The governance program was actually designed with multiple councils in mind. This is why the key accounts like TokenOwnerRecord or Proposal are keyed using governing_token_mint. We would have to make small change to support N councils but it’s definitely doable. The other ideas I’m thinking about are:
Require the councillors to keep their MNGO deposited while they are on the council. This way they would have skin in the game.
Have a council expiry and periodical elections
Limit council powers to well defined whitelisted set of instructions. This would constrained the decision the council could make
Grant some incentives to the council members for their effort
We could also setup multiple realms and use a single voter weight addin (single deposit source) for all the realms so the community token holders could still vote in all the realms at the same time, but I think I like the idea of a single DAO better.
I had a chat with Sebastian this weekend on how to handle this issue. For a short term period we should create a council token and a separate governance for updating the program to not grant the council additional rights over the treasury for instance. This will allow us to use the council to update the mango program even with short timeframes.
As the governance program matures, we will be able to decide on program updates, both through the regular governance token vote mechanism with 72h time delay as well as quick council votes. But for now the council will have mostly exclusive powers over program updates.
I nominate the following developers for this council:
This will ensure that all program updates will need to pass by 4 people to go into effect, the distribution is specifically chosen so that we have people around the world available to push the vote through, even if it is the middle of the night in one timezone.
private keys / votes can always be sold off-chain, we can only restrict & monitor on-chain activity, which is not necessary, given that someone trying to sell their multisig accees would most likely conduct and off-chain deal
I don’t understand. The council token is just like any other token right? They could sell it on chain?
I think this is good. I’m a little bit worried about 7 council votes. That means we have to gather up 4 people to do a program update which could be kind of annoying. I’d probably stay with 5 voters (excluding Jay and Sam). The remaining 5 are more likely to be deeply involved in the program updates since Sam is a designer and Jay has had minimal involvement with Mango program (AFAIK).
Main rationale here is to have quorom even when folks in the US are asleep. I’d prefer as well to keep the group tight, but we need +1 outside the US to avoid a “can’t deploy for the next 6 hours situation”.
Through the voter weight addin mechanism it’s possible to establish a council without using any tokens.
You can create a program which would manage the council members for the governance program. The advantages of this approach:
Council members wound’t be able to transfer their tokens (of course off-chain transfer of private key is still possible)
DAO could vote on both adding and removing council members
It would be possible to create an expiry for the council so the seats would have to be renewed by DAO vote, essentially establishing an election process
However using tokens for the council is just simpler. Assuming the council members are respectable members of the community the lack of inability to forcefully remove them from the council shouldn’t be an issue. And they can always voluntarily burn their council tokens
I started a vote so we can move ahead in the short term, while i’m preparing the vote weight add-in which will realistically take me some time to finish, given that we’ll need a new UI and some devnet testing period. I expect to finish it only early November.