I agree that this is needed. Perhaps there be a set criteria that has to be matched thereby triggering the emergency vote. I’m assuming that would be part of this. As long as the criteria is explicitly defined I see no reason why this isn’t a needed addition to voting.
There could even be the possibility for emergency recall vote during a pending 120 day period after passing an emergency vote in which the community can nullify the emergency if it’s deemed to not be in the greatest interest of the community as a whole for whatever reason.
Taking a longer term view through the governance lens an emergency vote could actually be something achieved through a DAO board that’s elected by the community to make these type of emergency decisions. I even think considering delegated voting might be something to explore as well to help speed up certain things like this.
My knee jerk reaction is concern for how “emergency power” could be exploited. If Anchor is to sit at the base of a widespread ecosystem of TeFi apps, improper “emergency power” could itself be an attack vector to destabilize “normal” transaction flow, particularly during times of peak volatility or low transaction volume.
Speaking for myself, I don’t see enough detail on this idea to be comfortable with it as is, but the idea is worth exploring. Can we add more definition/mechanics?
It still needs 51% of the vote… so it is still a ‘majority’
What kind of attacks are you thinking could happen?
I wanted to keep it as general as “update contract/call admin function” with 51% pass. so we can deal with most things that come our way.
I mean… you could potentially add some teeth where people voting ‘yes’ on an emergency vote would put their ANC at risk for the next X days (where a general vote could slash it)
Who decides it’s an emergency to begin with? The idea is ok, but the premise that something is labeled an emergency is actually an emergency doesn’t actually make it so. I’d think you’d have to have people agree it’s an emergency first, cause you can vote for something that you like, even if it’s not really an emergency and it would not really be representative of whether it’s an actual emergency, but rather the popularity of the proposal. You could pass “popular” governance proposals emergently when in reality they probably shouldn’t be.
While I can see the appeal of a fast-tracked decision process, I think we should tread very carefully around such implementation.
Mandatory delays are there to give the community time to acknowledge and analyze propositions, so that it can make educated decisions. They’re also here to protect the protocol from governance attack, by giving time to the community to rally around the vote and reject harmful propositions.
Eliminating the quorum and replacing it with a 51% of the shareholders in favor of the emergency provides a degree of security. But it also forces shareholders into rushed decisions and/or it might not even function that quickly at all if voter turnout remains low. Furthermore, it should not become the defacto upgrade mechanism for the protocol, unless the protocol is under existential threat.
The ThorChain Exploits are a good example of how rushed fixes can allow further damage to be inflicted down the road: the chain was exploited multiple times in a row, despite the rapid “fixes” released by the dev, eventually forcing them to bring the chain to a halt.
Hence, I would rather see us discuss a mechanism with a swifter execution time but a narrower scope, such as an emergency “freeze” mechanism, where a high portion of the shareholding can vote to freeze all contracts in order to give itself time to fix any sort of issue (hack, exploit, bug, unforeseen economical consequence,…).
This would provides 100% protection against governance attack via this vector since it doesn’t allow for the modification of the contracts, and prevent the mechanism from ever being used as an upgrade fast-track. That being said, it does not eliminate the risk of a Denial of Service attack by means of governance (a malicious actor with a sufficient share of the available ANC could perma-freeze the protocol), which means the mechanism should still be crafted with considerable care.
Here is for my honest opinion, I’m looking forward to reading your opinions about the original proposition and the emergency freeze option.
The emergency freeze is a good option (and one I didn’t think of)
My thoughts that I think we should discuss are what happens in a freeze situation around:
how it would work in a declining market where no-action might have repercussions on liquidations
how it would affect people who rely on the interest generated,
and can we actually stop/freeze aUST transfers, or 3rd party LP’s in bLuna/Luna
on the 51% (or the defined definition of a majority).
If the majority of token holders decide to perform an action, is that an attack vector, or just what the owners of the protocol want to do…
I think having a freezing option is also a great idea. @Spaydh thanks for bringing that to the table. I think it is useful and should be added to the tool bag. However, I tend to agree with @PFC who brings up great points here: mainly that freezes would not mitigate certain things. Therefore, this still leaves the door open for this needed emergency voting type feature.
I think the idea of making an emergency vote recallable limits the risk. Furthermore, stringent parameters would be set up so that these types of binary votes can only happen in certain situations on certain explicit parameters.
Again, looking further into the future, I think the key is here implementing a community elected DAO board to make these decisions. It also highlights the need for delegated voting so those that don’t wish to participate in these key decisions can delegate power to DAO board members or other trusted voting parties in the community that are more informed.
The more I think about it, the better this framing seems to fit. Initially, I was weighting each measure against each other, but I’m starting to think it’d be preferable to a combination of specific and narrowly defined tools at our disposal in order to respond to various threats as efficiently as possible, while minimizing overlaps and vulnerabilities.
This brings me to support the idea of an appointed board more. Even, possibly, that of delegated voting, although this creates a secondary problem:
This is a fair point, although I’d rather speak of a majority of tokens instead of holders. Token concentration, delegated voting and malicious acquisition of the tokens are three factors I can see as limitations to the veracity of the “majority of tokens staked in favor of an action = majority of users in favor of the action” equation.
I think the Curve war and the recent Mochi events illustrate well how creatively the “1 token = 1 vote” premise can be exploited down the road, and so these mechanisms deserve to be crafted with care.
These are three great elements to consider, and I’m hoping we can get inputs on this from bigger brains than mine. Here are some considerations from the top of my head, which I’ll try to update with more constructed suggestions.
I think it’s fair to say an emergency freeze is not a trivial event and that it should only occur if/when the protocol is under considerable threat. Should it happen to be coupled with adverse market conditions, would it be possible for the protocol to rely on the yield reserve as a buffer to “fund” the freeze? If the market reverses before the freeze is lifted, then no liquidation occurs. If the market continues to dip, the yield reserve is pulled in to ensure protocol solvency.
Obviously, the question becomes what happens if the dip extends beyond the value of the yield reserve. One solution could be to forcefully lift the freeze beyond a certain threshold (60/80/90% of the yield reserve?), either entirely (which would re-expose the protocol to the initial danger), or partially (re-enabling liquidations, which would no doubt be a source of great discontent for participants who have no other choice but see themselves get liquidated). Alternatively, the freeze could still be enforced, or the crossing of the threshold could trigger an emergency vote on the continuation of the freeze.
It’d probably be disastrous for them, but once again, the freeze should not be a trivial measure, and should not be weighted against the normal state of affairs but rather against other emergency measures.
Partial freeze mechanisms would allow for a more fine-tuned response to the threat (freezing only the endangered contracts and their direct dependencies for instance), but I’m not sure of just how feasible/risky they are. Triggering the freeze would require to set parameters more carefully, but it would, for example, allow borrowers to still withdraw the rewards from their position, as long as that part of the protocol is not involved in the threat that is justifying the freeze.
The economics around a modal freeze could be an issue though: what if the LP contract is left unfrozen because under no threat, and LPs decide to liquidate their ANC? Then, stakeholders with frozen assets (e.g. stakers) could be faced with considerable financial damage.
I’d love to know, but sadly I don’t. ^^’
That’s all the time I have right now but I’ll try to chime in asap. I’m looking forward to reading from both of you soon.