Proposal to Institute Emergency Governance Action

YamV1 died due to a fatal flaw in the code resulting in too many new YAM being minted during a positive rebase and being locked into the treasury. This prevented the ability of the community to achieve a governance quorum in the future, resulting in the inability to change the protocol from that point on or even access the treasury to redistribute the newly minted YAM.

In a last ditch attempt to correct this, the community as a whole rallied together to “Save YAM” through a governance vote to implement the corrected code into the protocol. However, this was unsuccessful due to the inability to execute the new code prior to the fatal rebase.

What I propose is the creation of an Emergency Governance Action that would supersede any other queued functions in the protocol once affirmed through governance. This would give the community a safety net to avoid another scenario like that which disabled YamV1.

In this scenario for example, if instead of calling a standard governance vote, the community called an emergency governance vote to insert the correct code in place of the flawed code. As soon as the emergency proposal was confirmed, it would have been executed ahead of any other transactions in the queue, thus neutralizing the fatal rebase.

Another possible execution of this idea would be to affirm a pause or cancellation of the rebase in order to give the developers time to implement the corrected code.

Although YamV3 will be audited, there is always the potential for undiscovered flaws, some of which could be fatal to the project once again. And without a centralized developer team in place, there is potential for YAM to move slower and much less decisively during emergency situations than other projects. In the spirit of hoping for the best but planning for the worst, I think it’s important that the community has a tool in place to take swift, decisive action if necessary.

Due to the potential for misuse, abuse, and manipulation by bad actors, I propose that the following rules control the emergency governance process:

  1. The threshold for proposing an Emergency Governance Action must be significantly higher than a standard governance proposal. This is to encourage that only those with a stake in the overall health and prosperity of the community are empowered to make such proposals.

  2. The address making the proposal must lock YAM to do so. I suggest the locking period should be 7 days, but am not married to that term. This is to prevent bad actors from attempting hostile takeovers of the protocol for pump and dump schemes. By requiring the proposer to lock their tokens, the protocol removes their ability to immediately profit off of the short term consequences of their proposal. It also allows the community to do their due diligence on the individual making the proposal and ideally counteract actions by bad faith actors through additional governance votes.

  3. The vote to “Save Yam” achieved overwhelming support from the community, amassing an extremely large percentage of votes. My belief is that future emergencies may and should require the same level of participation and activation from the community. With this in mind, I propose that instead of a quorum and simple majority for affirmation, as required by the standard governance procedure, Emergency Governance Actions should require a super-majority of token holders for affirmation. I would suggest starting at 60% but potentially higher. If an Emergency Governance Action received a majority affirmation but did not achieve a super-majority, then the proposal will have failed and will not be executed.

  4. I propose that all Emergency Governance Action proposals include the code intended to be implemented upon affirmation. This will give the community the opportunity to review the code and perform due diligence. Any proposal not including said code should utilize the standard governance proposal process instead.

  5. I propose that the voting period for an Emergency Governance Action be shorter than that of Standard Governance. This would allow such actions to be used to address time-sensitive flaws such as the fatal YamV1 rebase bug. I don’t know what exact timeframe is most practical, but I do think it should be less than the rebase cycle in case the protocol encounters another rebase bug in the future.

This is by no means a comprehensive set of requirements, but I am posting this so the community can weigh in on both the need, practicality, and safety of this proposal. I am also more than willing to concede my own ignorance as to the technical aspects and operations of the protocol under the hood. So if a technical feature makes this proposal moot or impossible to code and implement, I’m happy to be corrected and educated further.

8/25/2020 - Edits made for typos and clarity.


I think this is an excellent idea and should continue to be developed. Brock and I have discussed the need for some sort of safety mechanism, but hadn’t found a great way to do it in the current governance module. Your proposal gives some clear guidelines on how to enact such a mechanism.

I fear it might be a heavy lift prior to V3 launch, but I’ll let Brock weigh in on those particularly. Following V3 launch, this is definitely something I would love to see enacted.


Yeah I really like this. There are a couple outstanding issues around the fact that the tokens are currently so well distributed, delegation would have to be possible in this system. And since delegation doesn’t transfer tokens out of your account, I think the solution would need to be a separate emergency contract that has more privileges that people can delegate to for this to execute.

I will have to give it some more thought. Trent is right, this may be a bit heavy to get into V3 from the get-go though. Very interested in this longer term.


I agree with this we need to have some sort of emergency switch that can be triggered when needed

1 Like

The essence of this proposal makes total sense, however I believe an action like this is a very delicate one and should be given a lot of thought.

If the threshold to activate the “Emergency Governance Action” is too high we risk the chance of never achieving the goal, in the other hand if its too low the whole system may be hijacked by a group of whales or exchanges (Look at Steem take-over for reference).

Its good that you posted this here so we can get a discussion started but I think rushing this in before the v3 launch may be a bit hasty.


Thanks for all of the initial feedback everyone!

I agree, this is a lot to try to implement prior to V3, especially without a functioning treasury. In the context of the present development goals, I think it’s best to continue to stress rigorous auditing of V3 before launch and final migration.

To Chitty’s point, I agree that this will require a lot of fine tuning. Ideally, we wouldn’t want this to be used a ton (best case scenario, it never needs to get used at all). It should be reserved for emergencies which are time sensitive and threaten the whole protocol. For anything else, I think standard governance is perfectly satisfactory in terms of process and speed.

Regarding the fine tuning process, I wonder how feasible it would be to set up a testnet of some kind prior to implementing and then try as hard as we can to break the protocol on the testnet using the emergency governance feature with the idea that it would help us discover unanticipated vulnerabilities.


Nice idea on the testnet, you could set it up and ask people to try and break it. Buce bit of PR

This is great.

for #2 The vote locking could be for a considerable amount of time (6months, 1year) but if the rest of the community agrees and passes the proposal it could unlock the yams right then and there. That would be suitably high risk for bad actors and zero loss for good actors.


I agree with this we should definitely explore more about insurance funds and emergency governance voting after the V3 launch and We have a proper YIP proposal process.

I am exited for V3 launch. When audit?